コンタクトセンターが数分でポチッと構築できる。
いやいや、そんなばかな。
通販化粧品の会社で働いていたことがあります。
オペレータが増えたのに席の用意が間に合わない。
キャンペーンをやったら電話回線がいっぱいになってばんばんとりこぼす。
あの融通のきかない電話が、Amazonで簡単に。
もしあのときに Amazon Connect があれば、解決できたことがたくさんある気がして悔やまれます。
おそるおそるさわってみるとほんとうに簡単に電話システムができあがります。
少々制約がある点に気をつければ活用したもの勝ちだと思います。
もちろん初期費用はゼロ。使った分だけの従量課金です。
ほんとうにおそろしい。
もっと詳しく知りたい方は以下の資料が導入としておすすめです。
少々制約がある点に気をつければ活用したもの勝ちだと思います。
もちろん初期費用はゼロ。使った分だけの従量課金です。
ほんとうにおそろしい。
もっと詳しく知りたい方は以下の資料が導入としておすすめです。
心配な運用
簡単にコンタクトセンターが構築できることはわかった。
でも運用がまわるのかしら。
クラウドでみえないからこそ少し心配です。
どんなデータが蓄積されるのかを確認しましょう。
データ1)コンタクトトレースレコード (CTR)
各コールの詳細情報データです。
問い合わせ検索画面から確認することができます。
詳細情報から録音した音声も聞くことも可能です。
Amazon Kinesis Streams または Amazon Kinesis Firehose を使用して、サポートされている任意のデータリポジトリにストリーミングできます。
自由に分析できますね。
データ2)レポートデータ
以下のレポートデータが提供されています。
- リアルタイムレポート
コンタクトセンターの現在の状況を確認できる- キュー
- エージェント
- ルーティングプロファイル
- 履歴レポート
定期的にレポートをS3へ自動生成することが可能
グルーピング・フィルタして集計可能- キュー
- エージェント
- 電話番号
- エージェントのログインログアウトレポート
データ3)CloudWatchメトリクス
運用メトリクスとアラームに Amazon CloudWatch を使用します。
現時点(2018.05)のメトリクスの日本語訳を記載します。
メトリクス名 | 説明 |
CallsBreachingConcurrencyQuota | インスタンスの同時アクティブコールの制限を超過した音声コールの数。 これは、制限を超えた同時コールの数ではなく、制限を超えたコールの数です。 |
CallBackNotDialableNumber | 顧客の番号がインスタンスに発信コールが許可されていない国にあるため、顧客に返送されたキューに登録できなかった回数。 インスタンスに許可される国は、サービス制限によって定義されます。 |
CallRecordingUploadError | インスタンスに設定されているAmazon S3バケットにアップロードできなかったコール録音の数。 これは、インスタンスの[Data Storage/データストレージ]> [Call Recordings/コール記録]設定で指定されたバケットです。 |
CallsPerInterval | インスタンス内で1秒あたりに受信または送信された着信と発信の両方の音声コールの数。 |
ConcurrentCalls | データがダッシュボードに表示された時点の、インスタンス内の同時アクティブ音声コールの数。 このメトリックに表示される値は、ダッシュボードが表示されているときの同時アクティブコールの数であり、リフレッシュ間隔のセット全体の合計ではありません。 |
ConcurrentCallsPercentage | インスタンスで同時に使用されているアクティブな音声コールのサービス限度のパーセンテージ。 これは、ConcurrentCalls / ConfiguredConcurrentCallsLimit * 100によって計算されます。 |
ContactFlowErrors | コンタクトフローのエラー分岐が実行された回数。 |
ContactFlowFatalErrors | システムエラーのためにコンタクトフローが実行に失敗した回数。 |
LongestQueueWaitTime | 連絡先がキューで待機した最長時間(秒単位)。 これは、CloudWatchダッシュボードで選択されたリフレッシュ間隔(1分または5分など)中に連絡先がキュー内で待機した時間の長さです。 |
MissedCalls | 1分または5分などの、選択した更新間隔中にエージェントによって失われた音声コールの数。 不在着信とは、エージェントが20秒以内に応答しなかった通話です。 |
MisconfiguredPhoneNumbers | 電話番号が連絡先のフローに関連付けられていないために失敗したコールの数。 |
PublicSigningKeyUsage | コンタクトフローの顧客入力を暗号化するためにコンタクトフローセキュリティキー(パブリック署名キー)が使用された回数。 |
QueueCapacityExceededError | キューがいっぱいになって拒否されたコールの数。 |
QueueSize | キュー内の連絡先の数。 この値は、ダッシュボードにアクセスしたときのキュー内の連絡先の数を反映し、レポート間隔の期間は反映しません。 |
ThrottledCalls | 1秒あたりのコールレート(Callrate)がインスタンスの設定済み制限を超えたため、Amazon Connectサービスによって抑制された音声コールの数。 |
ToInstancePacketLossRate | インスタンス内のコールに対するパケット損失の割合.10秒ごとに報告されます。 各データポイントは0と1の間にあり、インスタンスのパケット損失率を表します。 |
データ保存期間
- アプリケーション内のコンタクトトレースレコード (CTR)、履歴的なメトリクスデータ、エージェントのパフォーマンスデータは、2年間保存
- 2年を超えてこのデータを保持するには、Kinesis Stream を使用して、Amazon Redshift などの任意のデータウェアハウスにコンタクトトレースレコードをストリーミングする方法があります
- S3に保存したレポート、通話の録音データはお客様が保存期間をコントロールできます
まとめ
これだけデータが用意されていれば運用もきちんとできそうな気がします。
問い合わせデータの分析はもちろん、CloudWatchで必要なメトリクスの監視をする設計をきちんとしたいですね。