Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

Amazon Connect における、予測、キャパシティプランニング、スケジューリングのトラブルシューティング - Amazon Connect

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

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

Amazon Connect における、予測、キャパシティプランニング、スケジューリングのトラブルシューティング

これらのセクションでは、予測、キャパシティプランニング、スケジューリングに関して、さまざまなトラブルシューティングシナリオを概説し、よくある質問について説明します。

予測

  • アドホック予測を作成するにはどうしたらいいですか?

    予測は自動的に処理され、短期予測は毎日、長期予測は毎週配信されるため、ユーザーは予測を手動で実行する必要がありません。ただし、履歴データを追加または変更するときに、予測がどのように更新されるかを確認したい場合があります。

    例えば、過去の問い合わせ量に異常があり、機械学習モデルでその異常を予測の構築に使用させたくない場合は、履歴データを変更し、新しい予測が実行されると、新しい予測にそのデータが組み込まれません。

    最新の予測を確認するには、[Last computed] (最終計算結果) 列を確認してください。

    新しい予測は、ユーザーがデータインポートタブを使用して履歴データをアップロードまたは削除したとき、または予測グループからキューを追加/削除したときに生成されます。

    [予測] タブのデータ、[最終計算] 列。
  • 履歴データをインポートすると、エラーが返されます。

    [download details] (詳細をダウンロード) を選択して、インポートされたデータが正しい形式であることを確認します。エラーがあった場合は、エラーの詳細を確認します。特定のエラーに関する追加の詳細が表示されます。ファイルが .csv 形式であること、小数点、余分な行、または列フィールドが含まれていないことを確認する必要があります。必要な形式の詳細については、「予測の履歴データのインポート」を参照してください。

    失敗ステータスメッセージ、[ダウンロードの詳細] リンク。
  • Forecast failed due to error: Insufficient data in Amazon Connect. (次のエラーにより予測が失敗しました: Amazon Connect のデータが不十分です。)

    このエラーが表示される場合は、次の 3 つの原因が考えられます。

    1. 履歴データが 6 か月未満です。この問題に対処するには、さらに履歴データをアップロードしてください。

      Amazon Connect は 6 か月分のデータを含む予測を生成できますが、コンタクトパターン (季節性など) が適切にキャプチャされるように、少なくとも 12 か月分の最近のコンタクトデータをお勧めします。6 か月分のデータがない場合は、予測の生成に使用される Amazon Connect 合成 (人工) データを提供できます。または、Override 関数を使用して、独自の予測をアップロードすることもできます。

    2. すべての予測グループで、1 か月あたり 2,000 件以上のコンタクトが必要です。Amazon Connect は、すべての予測グループに含まれるすべてのキューの履歴データを使用して予測を生成します。予測を正常に生成するには、Amazon Connect インスタンスについて、過去 6 か月間に毎月少なくとも 2,000 件のコンタクトが必要です。Amazon Connect では、キューごとに毎月 2,000 件のコンタクトが必要なわけではありません。すべての予測グループのすべてのキューの合計として、毎月 2,000 件を超えるコンタクトが必要です。

    3. 最新のデータが必要です。Amazon Connect は、すべての予測グループに含まれるすべてのキューの集計に基づいて、データ最新性チェック (データは十分最近のものか) を行います。予測を正常に生成するには、過去 4 週間に少なくとも 1 つのデータポイントが必要です。

  • データをインポートできない、予測をダウンロードできない、予測グループを作成できない、または予測を作成できない。

    ほとんどの場合、適切なアクセス許可がない可能性があります。管理者に問い合わせて、[Analytics, Forecasting - Edit] (分析、予測-編集) のアクセス許可を持っていることを確認してください。

  • 予測のオーバーライドアップロードが失敗しました。

    エラーメッセージをチェックして、.csv のファイル形式がデータスキーマに一致していることを確認します。必要な形式の詳細については、「予測の履歴データのインポート」を参照してください。

    ヒント

    計算または公開された予測 .csv ファイルをダウンロードします。オーバーライドの期間を取り、キュー ID とキュー名、タイムスタンプをオーバーライドテンプレートにコピーします。

    最後にアップロードされた .csv ファイルのみが使用され、以前にアップロードされたファイルは上書きされます。

  • 6 か月以上のデータをアップロードしても、長期予測が失敗しました。

    長期予測と短期予測のデータアップロードは独立しているため、長期予測と短期予測のデータを個別にアップロードする必要があります。まず、長期予測用に日次履歴データもアップロードしていないか確認してください。15~30 分間隔のデータは、短期予測のみを目的としています。次に、長期の日次レベルの .csv ファイルに、現在から連続して 6 か月以上カウントされた履歴データがあるかどうかを確認します。

  • 6 か月以上のデータをアップロードしても、長期予測が失敗しました。

    長期予測と短期予測のデータアップロードは、独立しています。日次データは、長期予測のみを目的としています。まず、短期予測用に 15 分または 30 分間隔の履歴データをアップロードしていて、ファイルに 6 か月以上の連続したデータが含まれているかどうかを確認します。次に、.csv ファイル内の予測間隔設定をチェックして、UI の履歴間隔と一致することを確認します。

  • 予測を公開できないのはなぜですか?

    予測を公開するアクセス許可がない可能性があります。また、予測 (短期と長期のコンタクトボリュームと処理時間の両方) が正常に生成されていない可能性もあります。[Analytics, Forecasting - Publish] (分析、予測 - 公開) のアクセス許可を持っているかどうかを確認し、予測が正常に生成されたかどうかを確認します (予測が生成されると、ステータス列に [complete] (完了) と表示されるはずです)。

  • 前の期間のデータを見るにはどうすればいいですか?

    過去に発生した、指定した期間の予測を表示できます。

    [短期] タブ、期間を選択するためのカレンダー。
  • 過去の予測データを見ることはできますか?

    最後に公開された予測と最後に計算された予測を表示できます。最後に計算された予測は、次の予測が計算された後に上書きされます。このデータを保持する場合は、最後に計算および公開された予測を含む.csvファイルをダウンロードできます。

  • キャパシティプランニングで使用される予測が、予測やスケジューリングに表示される予測と異なるのはなぜですか?

    キャパシティプランニングに使用される予測は、公開された最新の長期予測です。最新の計算済み予測と公開されている予測を比較すると、予測で異なる予測が表示される場合があります。スケジューリングで表示されるのは、最近公開された短期予測であるため、異なる予測が表示されます。

  • トラフィックがないと予想される深夜に、短期予測で通話量がピークに達するのはなぜですか?

    予測は、タイムゾーンとして協定世界時 (UTC) を使用します。太平洋岸または大西洋岸の北米ユーザーの場合、これは PST より 8 時間早く、PDT より 7 時間早く、EST より 5 時間早く、EDT より 4 時間早いです。例えば、UTC の午前 0 時は、PST の午後 4 時/PDT の午後 5 時、または EST の午後 7 時/EDT の午後 8 時です。

    重要

    履歴データまたはオーバーライドをアップロードする際には、UTC 時間を使用します。

  • 予測を削除できないのはなぜですか?

    予測は、キャパシティプラン (長期予測) またはスケジュール (短期予測) に使用されていない場合にのみ削除できます。予測が公開されているかどうか、また、スケジューリングやキャパシティプランニングに使用されているかどうかを確認してください。予測を削除するには、スケジュールまたはキャパシティプランを削除する必要があります。

  • 長期予測と短期予測で同じ期間について異なる値が表示されるのはなぜですか?

    この 2 つの予測は、目的に合わせて最適化されているため、トレーニングの頻度やモデルが異なります。短期は数週間にわたる間隔レベルの粒度を目的として設計され、長期は数か月にわたって日単位の粒度を目的として設計されています。

  • 長期平均処理時間は横ばいなのに、短期平均処理時間は変わらないのはなぜですか?

    平坦な平均処理時間は、数週間にわたる間隔粒度が表示されるため、短期予測ワークロードを予測する場合にパフォーマンスが向上します。長期予測で平均処理時間を変化させると、数か月にわたる日次粒度で表示されるため、パフォーマンスが向上します。

    ワークロードを計算する際には、処理時間が重要です。通常、短期的にはそれほど変化しませんが、長期間にわたって変化する可能性があり、これはモデルに反映されています。

  • コールボリュームは、着信時にカウントされますか、それとも通話終了時にカウントされますか?

    コールボリュームは、着信時にカウントを開始します。例えば、通話が午後 4 時 50 分に開始され、午後 5 時 5 分に終了したとします。これは、午後 4 時 45 分~午後 5 時間隔のコールボリュームとしてカウントされます。

キャパシティプランニング

  • キャパシティプランニングでは、縮小率をどのように処理すればよいですか?

    既存の予測グループについて、推定される将来のデータ (使用可能なフルタイム従業員数 (FTE) と縮小率を含む) を指定することで、キャパシティプランニングの精度を高めることができます。使用可能な FTE および縮小率データの提供はオプションです。Amazon Connect は、それらのデータがなくてもキャパシティプランを生成できますが、それらのデータを指定することでキャパシティプランの精度が向上します。そのデータをインポートするには、UI から .csv テンプレートをダウンロードし、空のセルに入力します。ユーザーは、作成した予測グループの正確な名前を入力する必要があることに注意してください。また、この .csv ファイルに複数の予測グループを追加できます。詳細については、「予想される将来の縮小率と使用可能なフルタイム従業員をインポートする」を参照してください。

  • キャパシティプランニングのデータインポート中にエラーが表示されます。

    .csv ファイル内の予測グループ名が、予測モジュール内の実際の予測グループ名と一致することを確認します。

スケジューリング

  • システムが、エージェントの一部またはすべてのスケジュールを生成しません。何を確認すべきですか?

    これは、エージェントをスケジュールできる最後の日付がスケジュールの時刻より前である場合や、エージェントの最大勤務時間によってそのシフトプロファイルで作業できないことが原因で発生する可能性があります。この問題を解決するには、以下の手順を実行します。

    1. [Staff Rules] (スタッフルール) をチェックして、スケジュールのないエージェントには [End date] (終了日) が設定されていないことを確認してください。[End date] (終了日) により、スケジューラはエージェントをスケジュールできる最後の日付を指定できます。

    2. シフトプロファイルをチェックして、[Start time] (開始時間) と [End time] (終了時間) の時間単位のスケジュールウィンドウが、エージェントあたりの [Mazimum working hours] (最大勤務時間) 以上かどうかを確認してください。

      例えば、シフトプロファイルが 8 時間のスケジュールを生成するように設定されている場合、エージェントのスタッフルールが 1 日あたり 4 時間動作するように設定されている場合、Amazon Connect はスタッフルールを適用し、4 時間のみスケジュールを生成します。

  • 会社の VPN を使用しているときに、スケジュールページにアクセスできないのはなぜですか?

    会社の VPN に、必要なエンドポイントへのアクセスを妨げるセキュリティ対策が講じられている可能性があります。会社の VPN に接続しているときにスケジュールページにアクセスできない場合は、管理者またはネットワークセキュリティチームに連絡して、以下のエンドポイントを許可リストに登録してもらってください。

    .awsapps.com/connect/markov/schedule-ui/api/graphql
    .my.connect.aws/markov/schedule-ui/api/graphql
  • 休憩後にランチアクティビティを指定したのに、一部のエージェントのランチアクティビティが最初の休憩アクティビティの前に予定されているのはなぜですか?

    これは、休憩とランチアクティビティが重複していることが原因である可能性があります。特定のシフトプロファイルをチェックして、両方のアクティビティの配置ウィンドウが重なっていないか確認してください。例えば、休憩アクティビティを午前 11 時から午後 1 時の間に設定し、昼食アクティビティを午前 10 時から午後 3 時の間に設定すると、システムは休憩を午後 12 時 30 分、昼食を午前 11 時 30 分に行うように設定することがあります。この問題を解決するには、アクティビティ配置ウィンドウが重なり合っている部分を削除するか、最小限に抑えてください。

  • エージェントが予定とは異なる開始時刻にスケジュールされるのはなぜですか?

    これは通常、タイムゾーンの問題が原因です。シフトプロファイルは協定世界時 (UTC) を使用して設定され、スタッフルールはエージェントが使用すべきタイムゾーンを指定します。この問題を解決するには、以下の手順を実行します。

    • [shift profile] (シフトプロファイル) の開始時刻と終了時刻が UTC タイムゾーンで設定されていることを確認します。

    • [Staff rules] (スタッフルール) UI で正しいユーザータイムゾーンが設定されていることを確認します。例えば、ボストン (EST タイムゾーン) のエージェントを午前 9 時から午後 5 時までスケジュールする場合は、次の操作を行う必要があります。

      • [シフトプロファイル] の開始時刻を午後 1 時に、終了時刻を午後 9 時に設定します。通常、シフトプロファイルは一度設定されると、後で再利用されます。

      • [Staff rules] (スタッフルール) UI で、すべてのエージェントのタイムゾーンを EST タイムゾーンに更新します。

  • 現地時間でスケジュールを表示することはできますか?

    はい。スーパーバイザーとスケジューラは、自分が管理するエージェントのローカルタイムゾーンでスケジュールを表示できます。エージェントは、各自のローカルタイムゾーンで個々のスケジュールを表示できます。ユーザーのタイムゾーンは、[Staff rules] (スタッフルール) UI で設定できます。

  • 電話やチャットなどのワークロードのアクティビティを定義する必要がありますか?

    いいえ。時間枠に休憩や昼食がスケジュールされていない場合、作業はスケジュールのデフォルトのアクティビティです。エージェントのアクティビティを定義するのは、エージェントが電話に出ていないときやチャットに応答していないときだけです。

  • 一部のエージェントが特定の日だけ名簿に追加されなかったのはなぜですか?

    エージェントを名簿に追加する方法は、最小/最大勤務時間、必要な最小スタッフ、最小/最大連続勤務日数など、人員配置グループとスタッフルールの複数の設定によって異なります。Amazon Connect は、定義された勤務時間を受け取り、スタッフグループとスタッフルールで定義された他のルールを考慮して、エージェントを名簿に追加します。

    例えば、最小勤務時間が 40 時間であり、エージェントが 1 日 12 時間、週 6 日勤務するスタッフグループに属している場合、エージェントにはスケジュールのない日がある可能性があります。このサービスは、予測に基づいてスケジュールを最適化します。最小週 40 時間 (1 日 10 時間で 4 日間) を満たしている限り、コールボリュームが少ない日にはエージェントが配置されない場合があります。エージェントに 1 日のスケジュールがない場合は、エージェントの最小勤務時間を確認してください。また、そのエージェントがその週の残りの時間に名簿に追加されているかどうかを確認してください。

  • エージェントのスケジュールされた時間がシフトプロファイルの時間と異なるのはなぜですか? 例えば、私のシフトプロファイルでは平日は 10 時間ですが、私のエージェントは 6 時間しかスケジュールされていません。

    シフトプロファイルの営業時間はスタッフグループに適用されます。シフト開始時刻のスタッフグループルールを設定しない場合、Amazon Connect は予測ワークロードに基づいてエージェントの開始時刻を最適化します。

    例えば、シフトプロファイルでは月曜から金曜の午前 8 時~午後 6 時が設定されていて、午前中はワークロードが軽く、午後が重いとします。各エージェントは、1 日あたり最小 6 時間、最大 8 時間です。エージェントのコストを節約するために、Amazon Connect では午前中にスケジュールするエージェントの数を減らし、午後にスケジュールするエージェントの数を増やします。午前 8 時に開始するエージェント、午前 8 時 30 分に開始するエージェント、または午後に開始するエージェントもいます。6 時間のスケジュールを持つエージェントもいれば、8 時間のスケジュールを持つエージェントもいます。このようにして、エージェントリソースを最大限に活用してサービス目標を達成できます。すべてのエージェントを同じ時間に開始し、正確な時間数を勤務させたい場合は、スタッフグループの [shift start time] (シフト開始時間) のルール [start at the same time] (同じ時間に開始) に設定し、[working hour] (勤務時間) を毎日 10 時間に設定できます。この場合、予測に基づいて最適化する柔軟性が低いため、エージェントのコスト削減は少なくなります。

    作業時間、必要最小限のスタッフ、シフト開始時間のルール。
  • 私のエージェントは全員正社員であり、1 日 8 時間勤務しています。スケジュールにこれを設定するにはどうしたらいいですか?

    スタッフグループとスタッフの最大勤務時間および最小勤務時間を 1 日 8 時間に設定します。

  • 正社員と派遣社員が混在しています。それを定義する最善の方法は何ですか?

    ベストプラクティスは、スタッフグループを使用して勤務時間を 8 時間に設定し、次にスタッフルールを使用して、個々のパートタイムエージェントの勤務時間を特定の値に設定することです。スタッフルールの値は、スタッフグループの値を上書きします。

  • ミーティングや 1 回限りのイベントを追加するにはどうしたらいいですか?

    まず、毎日のアクティビティを含むスケジュールを作成します。スケジュールマネージャービューで任意のスケジュールを選択し、[add shift] (シフトを追加) を使用して 1 回限りのシフトアクティビティをスケジュールに追加します。

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.