本文へスキップ
tech公開更新約8分で読めます

コールセンターの呼量予測で異常日をどう扱うか ー 障害・販促・連休の補正手順

シェア
【FC要修正】コールセンターの呼量予測で異常日をどう扱うか ー 障害・販促・連休の補正手順

呼量予測が外れる日は、たいてい通常日ではない。システム障害、大型販促、連休明け。こうした日を「イレギュラーなので予測から除外」と処理した瞬間、その日の情報は永久に失われる。そして翌年の同じ連休で、また同じように外す。呼量予測の精度を上げる作業の大半は、モデルの選定ではなく、この異常日をどう扱うかという地味な運用設計に費やされる。本稿はWFM担当者向けに、異常日の記録から予測への反映までの手順を編集部の実務設計案としてまとめる。

コールセンターの異常日は削除せず理由別に記録する

最初の原則は、異常日を消さないことだ。

呼量予測ツールは基本的に、過去の実績から将来を推定する。Amazon Connectの予測機能も、過去のメトリクスをもとに将来の入電数と平均処理時間(AHT)を予測する仕組みで、長期予測は64週分を週次更新、短期予測は18週分を日次更新すると説明されている(同社ドキュメント)。過去実績が入力である以上、異常日を実績から削除すると、モデルにとってその日は「なかった日」になる。

だが現実には、その日は来年も来る。連休は毎年ある。大型販促は毎回ある。障害は不定期だが、リリース直後という条件では繰り返す。削除は「予測しない」という意思決定であり、精度改善ではない。

やるべきは、削除ではなく理由のラベル付けだ。最低限、次の4項目を日付ごとに残す。①日付と時間帯 ②理由の分類(障害・販促・連休・報道・制度変更・その他)③きっかけの詳細(どのシステムが何時間停止したか、どのキャンペーンが何媒体で告知されたか)④通常日比の倍率(呼量とAHTの両方)。

家計簿にたとえるなら、冠婚葬祭の出費を「イレギュラーだから記録しない」とするか、「冠婚葬祭」というラベルを付けて記録するかの違いに近い。前者は毎年同じ驚き方をし、後者は3年目に予算を組める。

販促と障害は再現性が違うので分ける

異常日を全部同じ扱いにしないことが、次の分岐点になる。理由によって再現性がまったく違うからだ。

連休・季節要因は、日付が事前にわかる。再現性が最も高く、過去2〜3年の同一条件(連休の長さ、曜日の並び、月初か月末か)を並べれば倍率の目安が取れる。予測への反映も、事前の上乗せという形で計画に織り込める。

販促・キャンペーンは、実施が事前にわかるが、規模が毎回違う。ここで有効なのは、呼量そのものではなく「告知量あたりの入電」を係数として持つことだ。メール配信数やテレビCMの投下量に対する入電の比率を記録しておけば、次回の告知規模から推定できる。同じ「販促日」でも、DM10万通と100万通を同じ倍率で扱えば当然外れる。

障害・不具合は、事前にわからない。したがって予測に織り込むのではなく、発生時の対応計画として持つのが筋になる。ただし「起きたときにどのくらい増えるか」は記録から推定できるので、影響範囲(全ユーザーか一部か)と停止時間に対する倍率をレンジで持っておくと、当日の増員判断が速くなる。

報道・SNS拡散は、再現性が最も低い。無理に予測へ反映せず、記録だけ残して事後の振り返りに使う。

この分類を先にやらずに「異常日補正」をひとまとめの係数でかけると、再現性の高い連休の精度まで、再現性の低い報道の分散に引きずられて劣化する。

通常日の予測と上振れ時の予測を別に作る

実務では、1本の予測だけを持つのではなく、2本持っておくと判断が速い。通常日を前提とした基準予測と、異常日を織り込んだ上振れ予測だ。

このとき、上振れ予測は「基準予測 × 倍率」で作る。倍率は前節の分類ごとに持つ。重要なのは、呼量とAHTを別々の倍率で持つことだ。障害時は呼量が増えるだけでなく、1件あたりの説明が長くなってAHTも伸びる。呼量だけを1.5倍にして要員を積んでも、AHTが1.3倍になっていれば必要工数は約2倍で、手当てが足りない。

ツール側でこの上乗せを扱う場合、たとえばAmazon Connectの予測編集機能では、CSV形式のオーバーライドファイルで予測値を上書きできる。同社ドキュメントによれば、オーバーライドファイルは予測グループごとに1つしかアップロードできず、新しい上書きを追加する場合は既存のファイルに書き足して再アップロードする必要がある。また、入電数と平均処理時間の両方が1つのファイルに含まれ、両方の列を埋める必要があるとされている。保持されるのは最後にアップロードしたファイルのみで、変更時は最新版をダウンロードして編集する運用になる。

ツールの仕様として押さえておきたいのは、この「1ファイル1グループ・両列必須・最新のみ保持」という制約が、そのまま運用ルールになるという点だ。誰がマスターファイルを持ち、いつ更新するかを決めておかないと、上書きの上書きで過去の補正が消える。

実績との差を次回へ戻す

異常日の補正は、一度作って終わりにならない。振り返って倍率を更新する工程まで含めて手順である。

振り返りで見る数字は、絶対誤差ではなく方向と幅にしたい。①予測に対する実績の倍率(上振れか下振れか)②ピークの時間帯がずれたか ③AHTの伸びが想定内か ④翌日以降への持ち越し(呼び返し・再入電)がどのくらい出たか。

④は特に見落とされやすい。障害当日に取りきれなかった呼は消えるのではなく、翌日に移る。当日だけを評価すると「思ったほど来なかった」と見えて、翌日の要員を薄くしてしまう。異常日は当日と翌営業日をセットで振り返る。

こうした振り返りを回すには、日次の予実がすぐ見える状態が要る。Amazon Connectには当日中の予測パフォーマンスを見るダッシュボードも用意されている(同社ドキュメント)。ツールがどれであれ、当日中に予実の乖離が見えるかどうかで、対応の速さは変わる。

なお、異常日のラベル定義と補正の倍率は、自社データがなければ決められない。本稿で示した分類・4項目の記録・倍率の持ち方は編集部の設計案であり、業種や商材によって当てはまり方は変わる。他社の倍率を借りてくることに意味はない領域である。

ここからは私の見立てとして

ここからは私の見立てとして書く。呼量予測の議論はAIモデルの話に寄りがちだが、精度を最も大きく動かしているのは、たぶん入力データの手入れの側だと思う。異常日を消してきた現場と、理由付きで残してきた現場では、3年後に使えるデータの量が違う。モデルを入れ替えても、この差は埋まらない。

自己反証をひとつ置く。この主張は「記録さえ残せば読めるようになる」と言い過ぎているかもしれない。呼量が小さいセンターでは、そもそも1件の増減がノイズに埋もれ、異常日の倍率を統計的に語れるほどのサンプルが溜まらない。小規模センターでは、倍率よりも「その日に誰を呼べるか」という人繰りの選択肢を増やす方が、実効性は高いはずだ。

その留保つきで、順序としてはこうなる。第一に、異常日を削除せず理由付きで記録すること。第二に、再現性で分類を分け、連休と販促と障害を同じ係数で扱わないこと。第三に、呼量とAHTを別の倍率で持ち、当日と翌営業日をセットで振り返ること。

では、直近1年で最も外した日は、どの分類の日だったのか。その1日の記録が今どこにあるかを探すところから始めるのが早い。

よくある質問

Q1. 異常日は予測データから除外すべきですか? A. 除外は勧めません。除外するとモデルにとって「なかった日」になり、翌年の同じ日をまた読めなくなります。理由をラベル付けして残し、再現性で分類する方が実務的です。

Q2. 補正の倍率はどのくらいが目安ですか? A. 汎用的な目安はありません。業種・商材・告知手段によって差が大きいため、自社の記録から算出する必要があります。他社の倍率を借用しても機能しません。

Q3. 呼量とAHTは同じ倍率でよいですか? A. 分けるべきです。障害時は入電数が増えるだけでなく1件あたりの説明も長くなるため、AHTも伸びます。呼量だけを補正すると必要工数を過小に見積もります。

小規模センターの相談事例を読むなら

呼量規模が小さい現場での判断軸については、実際の相談を再構成したモデルケースを会員向けに公開しています。

小規模センターは、生成AIとどう付き合うべきか(会員限定)

注記

本稿は2026年9月11日時点の公開情報に基づくデスクリサーチであり、見解は筆者個人のものである。本文中の異常日分類・記録4項目・倍率の持ち方は編集部の実務設計案であり、特定の調査や標準に基づく推奨値ではない。Amazon Connectの仕様は同社の公開ドキュメントの記述に基づくが、機能は更新される可能性があるため、導入時は最新のドキュメントを確認されたい。本稿はAIによるデスクリサーチに基づいて執筆している。


出典

関連して読まれている記事

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと隔週ニュースレターを受け取れます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア