SaaSのサポート窓口が過去の入電・チャットの数と施策の予定表から Python で2週間先の日ごと・時間帯ごとの問い合わせを見込み、席数の案を作る

処理の起点を決める

毎週木曜の夜と、施策の予定表が変わったときに動かします。 木曜に出すのは、運用の担当が金曜に翌々週のシフトの枠を組むからです。施策の予定表は共有フォルダの表なので、変更の日時を1時間ごとに見に行き、前回から変わっていれば出し直します。

出し直すのは、変わった施策の前後の日だけではなく、向こう2週間の全体です。施策が1つ増えると、近くの日の見込みも動くことがあるからです。ただし、シフトが確定済みの日の席数は書き換えず、差だけを知らせます。

月の初めには、前の月の見込みと実際の受付数の差をまとめて出します。外れた日と、その日にあった施策を並べ、施策の予定表の書き方の改善に使います。

入力データを集める

質を決めるのは、施策の予定表です。 施策の種類は、全利用者へのメール配信、一部の利用者へのメール配信、無料体験のキャンペーン、料金改定のお知らせ、新機能のリリース、計画的なメンテナンス、法改正への対応のアップデートの7つに分けます。種類を細かくしすぎると、1つの種類あたりの過去の例が少なくなります。

障害の記録は、学ばせない時間を決めるために使います。 サービスの障害が起きた時間の問い合わせは、施策とも暦とも関係なく跳ねます。この時間を学ばせると、同じ曜日・時刻の見込みが多めにずれます。

データの取得方法を決める

電話とチャットの受付の仕組みから、1時間ごとの受付数と平均の対応時間を、決まった列の並びで書き出す設定を作ります。多くの受付の仕組みには、時間帯ごとの集計を書き出す機能があります。連携の機能で自動化できるかは、それぞれの提供元に確かめます。 最初は担当者が週に1回書き出して共有フォルダに置く運用で始められます。

祝日は、内閣府のページから「国民の祝日」の表を取ります。 昭和30年（1955年）から令和9年（2027年）までが表の形で載っていて、令和10年（2028年）の分は前年の2月に載せるとされています。年に1回、2月に取り直す予定を運用の手順に入れておきます。

AIへ渡す前に整形する

1. 放棄の数を足す … 電話は、つながらずに切られた数を受付数に足します。席が足りなかった時間ほど受付数が少なく出るので、そのまま学ばせると少なめに見込みます
2. 障害の時間を外す … 障害の記録の時間と、その後の2時間を学ばせる記録から外します
3. 利用者の数で割る … 1時間ごとの受付数を、その月の契約の利用者数1万社あたりに直して学ばせ、見込みのときに戻します。利用者が増えた分を、前年の数に上乗せするためです
4. 施策を項目に直す … 施策の種類ごとに、「開始からの経過時間（0〜168時間、それより後は値なし）」と「対象の数」の列を作ります
5. 暦を項目に直す … 曜日、時刻、祝日、月末からの日数、給与の締めの日からの日数、年末年始の印
6. 窓口を分ける … 電話とチャットで別のモデルを学ばせます。施策の効き方が窓口によって違うからです
7. 受付時間外を外す … 電話の18時以降、土日を学ばせる記録と見込みの対象から外します

1番目を軽く見ないでください。 施策の山の日は、まさに席が足りずに放棄が多い日です。放棄を足さずに学ばせると、施策の効き方が小さく見え、次の山でもまた席が足りなくなります。 同じ人がかけ直した分が二重に入るので、放棄の数は半分を足す、のように自社で規則を決めます。

AIに処理させる

させるのは、窓口ごと・1時間ごとに「問い合わせが平均で何件来るか」を見込むことだけです。 多めの数、施策ごとの上乗せの内訳、席数への換算、印付けは、決まった計算で行います。

施策ごとの上乗せは、同じモデルに「その施策が無かった場合」の項目を入れてもう一度見込み、その差で出します。 運用の担当には、「火曜10時の見込み85件のうち、料金改定のお知らせの分が30件」のように見えます。この内訳があると、マーケティングに配信の時刻をずらしてもらう相談ができます。

1日の合計を見込んでから時間に割り振る形にしないのは、意図してのことです。 施策の山は1日の中で偏ります。メール配信の山は配信から2〜3時間、リリースの山は朝の始業の時間に来ます。1日の合計を曜日ごとの時間の割合で割ると、山の時間が薄まり、 席が足りないのはまさにその時間になります。1時間ごとに直接見込めば、施策の経過時間の項目がそのまま山の形を作ります。

多めの数は、ポアソン分布の9割の位置だけでは足りません。 実際の問い合わせは、ポアソン分布の想定よりばらつきます。そのため、過去の見込みで実際に9割の時間が多めの数を下回っていたかを確かめ、 下回っていなければ、平均に掛ける倍率を足して調整します。

4行目がいちばん起きやすい失敗です。 毎月同じ時期に配信があったからといって、予定表に無い配信をモデルが勝手に見込むと、施策が取りやめになった月に席が余ります。 予定表に書かれないものは見込みに入れず、代わりに予定表を書く運用を守ってもらいます。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、モデルの設定と換算の規則を書いておきます。

【モデル（窓口ごとに1つ）】
- HistGradientBoostingRegressor(loss="poisson")
- 目的の値 = 1時間ごとの受付数（放棄の半分を足す）÷ 利用者数（1万社あたり）
- categorical_features = ["weekday", "hour", "holiday", "season_flag"]
- 施策の項目 = 種類ごとの経過時間（0〜168、範囲外は NaN）と対象の数
- monotonic_cst で「対象の数」は増える向きに制約する
  （配信数が多いほど問い合わせが減る、という形を学ばせない）
- 学ばせ方と確かめ方は TimeSeriesSplit
  ・test_size = 2週間分、gap = 1週間分（木曜に翌々週を見込む使い方にそろえる）

【多めの数】
- 多め = poisson.ppf(0.9, 平均 × 倍率)
- 倍率の初期値 = 1.0。毎月、過去8週で実際の受付数が多めを
  下回った時間の割合を数え、0.85 未満なら倍率を 0.05 ずつ上げる

【施策ごとの上乗せ】
- 上乗せ = 見込み（施策あり）− 見込み（その施策の列を NaN にしたもの）
- 同じ時間に施策が2つ以上あれば、それぞれの上乗せと、両方を外した差を並べる

【席数への換算】
- 電話 … 多めの数と平均の対応時間から、待ち行列の式（アーランC）で
         「80％の電話に20秒以内に出る」を満たす最小の席数
         ＋ 休憩・後処理の分として 1 ÷ (1 − 0.3) を掛け、切り上げ
- チャット … 多めの数 × 平均の対応時間 ÷ 60 ÷ 同時に受ける数（2）を切り上げ

【印を付ける条件】
- peak     … 施策の上乗せが、その時間の見込みの3割以上
- new_type … 過去の例が3回未満の種類の施策がある
- overlap  … 同じ時間に施策が2つ以上
- shift    … 前回の出し直しから席数が2席以上動いた
- locked   … シフトが確定済みの日に席数の差が出た（書き換えず知らせる）
- 印の無い日は、運用の担当の確認なしで席数の枠に書く

monotonic_cst を入れるのは、意図してのことです。 過去の施策の数が少ないと、「配信数が多いのに問い合わせが少なかった」1回の例を学んで、配信数が増えるほど問い合わせが減る形を作ることがあります。 増える向きに制約しておけば、その形は出ません。

電話に待ち行列の式を使い、チャットに使わないのは、待ち方が違うからです。 電話は1人のオペレーターが1本ずつ受け、空いた席が無ければ利用者は待ち続けます。1時間に来る数と1本あたりの対応時間が分かれば、「何席あれば何割の電話に何秒以内に出られるか」を式で出せます。チャットは1人が同時に複数を受けられ、返事が数分遅れても利用者は待っていてくれるので、 必要な対応の時間を同時に受ける数で割る簡単な換算で足ります。

待ち行列の式の目標（80％を20秒以内）は、自社の目標に置き換えてください。 ここは見込みの精度より、どれだけのつながりやすさにいくらの人件費をかけるかという経営の判断です。

出力形式を固定する

窓口・日・時間ごとに、次の形のJSONを作り、表にしてシフトの管理表へ渡します。

{
  "channel": "phone | chat",
  "date": "",
  "hour": 0,
  "forecast": { "mean": 0, "p90": 0 },
  "baseline_without_campaigns": 0,
  "campaign_uplift": [
    { "campaign_id": "", "type": "", "uplift": 0 }
  ],
  "aht_sec": 0,
  "seats": { "required": 0, "planned": null },
  "flags": ["peak | new_type | overlap | shift | locked"],
  "model_version": "",
  "planner_override": { "seats": null, "reason": "" }
}

1つ目の理由は、baseline_without_campaigns と campaign_uplift を分けて見せられることです。 施策が無ければ何件で、どの施策で何件増えるのかが1行で分かります。マーケティングとの相談は、この2つの列だけで足ります。

2つ目は、required と planned を分けて持てることです。 required は計算で出した席数、planned は運用の担当がシフトに書いた席数です。両方を残すと、席数を削った時間に放棄が増えたかを後から確かめられます。

3つ目は、planner_override で直した記録が残ることです。 運用の担当が「この配信はいつもより反応が小さい」と判断して直したら、その理由を書きます。どちらが当たったかを、翌週に比べられます。

システムへ連携する

受付の仕組みへは書き込みません。 出すのは席数の枠の案までで、シフトを確定させるのは運用の担当です。 確定済みの日を書き換えないのは、オペレーターに伝えた勤務を勝手に変えないためです。

人が確認する

人が開くのは、印の付いた日だけです。 印の無い日は、席数の枠の表を流し見ます。全件を開く設計にすると、第10章の8.0時間には収まりません。

1. new_type を先に見る … 過去の例が少ない施策は、見込みが当てになりません。施策の担当に、対象の数と案内の中身を聞いて判断します
2. overlap と peak を見る … 施策が重なる時間は、配信の時刻をずらせないかをマーケティングに相談します
3. shift を見る … 席数が大きく動いた理由が、施策の予定の変更か、直近の受付数の変化かを確かめます
4. locked を見る … 確定済みの日に足りない席が出たら、残業や応援の手配を責任者と決めます
5. 直したら理由を書く … planner_override に値と理由を残します

2番目が、この構成のいちばん効く使い方です。 席を増やすより、配信を1時間ずらしてもらうほうが安く済むことがあります。内訳が見えていれば、その相談を配信の前にできます。

例外に対処する

上から3行目と4行目が大半を占めます。 どちらもモデルの問題ではなく、施策と障害の情報がサポートに届く速さの問題です。 施策の予定表と障害の報告を同じ連絡の場に流すほうが、精度を上げる工夫より効きます。

記録を残す

• 読み込んだ受付数の書き出しのファイルと、書き出した日時
• そのときの施策の予定表の内容（変更の前後を両方残す）
• 窓口・日・時間ごとの見込み、多めの数、施策ごとの上乗せ
• 席数の計算に使った目標と平均の対応時間
• 運用の担当が直した値と理由
• 実際の受付数と放棄の数、見込みとの差
• 多めの数の倍率と、それを決めたときの「9割を下回った時間の割合」

最後の行は、倍率を上げ下げした理由を残すためです。 倍率は席数にそのまま効くので、誰がいつ何を見て変えたかが残っていないと、人件費が増えた理由を説明できません。

2つ目で施策の予定表の変更の前後を残すのは、外れた理由を後から分けるためです。 見込みが外れた日が、モデルの外れなのか、予定表が直前に変わったのかで、直すところが違います。予定表の変更が配信の何日前だったかを数えると、マーケティングとの約束（何日前までに書くか）を決める材料になります。