SaaS 企業のサポートがチケットの記録・リリースの予定・契約数から Python で翌週の分類ごとの問い合わせの件数を予測し、初回の返信の目標を守る担当の割り振りの案を出す

処理の起点を決める

取り込みは毎日の深夜、予測は木曜の朝と月曜の朝に動かします。 取り込みを毎日にしておくのは、Zendesk から1週間分をまとめて取ると、取り込みが失敗した日に気づくのが木曜になるからです。社内のサーバーか、クラウドの小さな仮想マシンの定時実行（cron）で Python のスクリプトを起動します。

木曜の朝は、翌週の割り振りを決めるための回です。 金曜に担当の予定の表を確定させるので、木曜のうちに案を見て、開発に応援を頼める時刻にします。月曜の朝は、週末に入ったチケットを足して、その週の残りの日を予測し直す回です。 週末に大きな障害があった週は、月曜の残りが平常の週と違います。

月に1回、モデルを作り直します。 毎月の第1木曜に先月までの記録で学習し直し、作り直す前と後で、先月の当たり方を比べた結果を残します。悪くなっていれば、前のモデルのまま使います。

結果の表には、作った日時と、最後に取り込みが成功した日時を必ず印字します。 取り込みが止まっていると、直近の件数が少なく見え、翌週を少なく見込みます。

入力データを集める

質を決めるのは、リリースの予定表の「画面が変わるか」の列です。 同じリリースでも、内部の改善だけのリリースと、画面の並びが変わるリリースでは、使い方の問い合わせの増え方がまるで違います。 開発に1列足してもらうだけで、モデルが両者を見分けられるようになります。

障害の日を記録しておきます。 大きな障害の日は、不具合とログインの問い合わせが一気に増えます。障害は前もって分からないので、予測の対象にしません。 学習のときに外すため、障害の日と時間帯を記録します。

祝日は内閣府の CSV を使います。 祝日の CSV は、翌年の分が前の年の2月に載るとされているので、年に1回、2月に入れ替えます。

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

最初の1回だけ start_time を渡し、2回目からはカーソルで続きを取ります。 公式のページでは、start_time は Unix の秒で指定し、少なくとも1分前でなければならないとされています。前回の応答の after_cursor を保存し、次の日はそこから呼びます。end_of_stream が true になるまで呼び、その日の取り込みを終えます。

同じチケットが何度も届くことを前提にします。 この書き出しは、作られたチケットだけでなく、前回から変わったチケットを返します。 公式のページでは、比べるのはチケットの updated_at ではなく generated_timestamp で、システムによる更新でも値が変わるとされています。担当が返信しただけでも、同じチケットがまた届きます。チケットの番号で重複を除き、件数は作成日時で数えます。

削除したチケットは、既定で書き出しに含まれます。 迷惑メールとして削除したものが件数に入らないよう、exclude_deleted=true を付けるか、削除の印のあるものを外します。 1分あたり10回までの制限があるので、ページを続けて取るときは間を空けます。

AIへ渡す前に整形する

1. 重複を除く … チケットの番号ごとに最後に届いたものだけを残します
2. 数えないものを外す … 迷惑メール、削除したもの、ほかのチケットに統合されたもの、自動の返信（不在の通知など）を外します
3. 作成日・分類ごとに数える … 作成日時で営業日ごとに、5つの分類ごとの件数にします。土日に作られたものは月曜の分に足します
4. 障害の日を外す … 記録した障害の日と翌営業日は、学習の行から外します
5. 率にする … 件数をその日の契約の数で割り、1,000を掛けて「契約1,000社あたりの件数」にします
6. 項目を作る … 分類、曜日、祝日の翌日か、月、月末からの日数、請求書の発行の日からの日数、直近のリリースからの日数、その規模、画面が変わったか、対象の機能が分類に関係するか、お知らせのメールの有無、契約から30日以内の利用者の割合、直近4週の同じ曜日の率の平均
7. 分類・曜日・リリースの規模を Categorical にする … pandas の Categorical の型にしておけば、既定の設定でカテゴリとして扱われます

1番目と3番目が、この構成の肝です。 重複を除かずに数えると、返信のやり取りが多い不具合のチケットほど何度も数えられ、件数が膨らみます。 更新の日時で数えると、リリースの週の件数が、翌週の返信の日に移ってしまいます。件数は必ず、チケットの番号ごとに1回、作成日時で数えます。

4番目で障害の日を外すのは、障害の山を学習すると、ふだんの週を多めに見込むからです。 障害の日が過去のリリースの日と重なっていると、モデルはリリースの効き方を大きく覚えます。

AIに処理させる

させるのは、翌週の日ごと・分類ごとの「契約1,000社あたりの件数」を予測することだけです。 機械学習のモデルを2本作ります。

上振れに0.9を使うのは、目標を外したときの戻りが大きいからです。 返事を待つ利用者が同じ問い合わせを送り直し、残りがさらに増えます。どの分位を使うかは、目標を外す重さと、応援を頼む開発の負担のどちらを重く見るかで、責任者が決めます。

未返信の残りは、日ごとに足し引きします。 その日の件数の見込みと前日の残りを足し、その分類の担当の処理できる件数を引いたものが、その日の終わりの残りです。 処理できる件数は、担当の出勤の時間を、分類ごとの1件あたりの処理の時間で割って出します。

初回の返信の目標が営業日の4時間以内なので、「翌日の午前に返せるか」で見ます。 残りが翌日の午前に返せる数を超えると、前日の夕方に来た分が目標を外します。

3行目は、とくに気を付けてください。 上振れの赤の日が出ても、それを理由にリリースを延ばす判断に予測を使わないでください。 予測はサポートの割り振りを決めるための見込みです。

指示内容を固定する

生成AIを使わないので、プロンプトはありません。 かわりに、率の予測と未返信の残りの足し引きの中身を示します。

from sklearn.ensemble import HistGradientBoostingRegressor

FEATURES = ["queue", "weekday", "after_holiday", "month", "days_to_month_end",
            "days_since_invoice", "days_since_release", "release_size",
            "ui_changed", "release_hits_queue", "notice_mail",
            "new_contract_share", "recent4w_same_rate"]
# queue・weekday・month・release_size は pandas の Categorical にしておく

train["rate"] = train["tickets"] / train["contracts"] * 1000
w = train["contracts"] / 1000

# 直近の8週を検証に取り分け、時間の順を守って早期の打ち切りに使う
cut = train["date"].max() - pd.Timedelta(weeks=8)
tr, va = train[train["date"] <= cut], train[train["date"] > cut]

def hgb(**kw):
    return HistGradientBoostingRegressor(max_iter=600, learning_rate=0.05,
                                         random_state=0, **kw)

center = hgb(loss="poisson")
upper  = hgb(loss="quantile", quantile=0.9)
for m in (center, upper):
    m.fit(tr[FEATURES], tr["rate"], sample_weight=w[tr.index],
          X_val=va[FEATURES], y_val=va["rate"], sample_weight_val=w[va.index])

def backlog(arrivals, capacity, start=0):
    """日ごとの終わりの未返信の残り"""
    out, b = [], start
    for a, c in zip(arrivals, capacity):
        b = max(0, b + a - c)
        out.append(b)
    return out

検証を X_val と y_val で渡しているのは、時間の順を守るためです。 公式のページでは、early_stopping の既定の 'auto' は、行が10,000を超えるときか、X_val と y_val を渡したときに有効になるとされています。validation_fraction は学習の行から一定の割合を取り分ける指定で、直近の週を選ぶ指定ではありません。 未来の週で学習して過去の週で確かめることになりかねません。直近の8週を検証に取り分ければ、早期の打ち切りが働き、時間の順も守れます。

当たり方の確認は、TimeSeriesSplit で週の順に行います。 公式のページでは、時間の順に並んだデータで、k 回目は最初の k の区切りで学習し、次の区切りで確かめる分け方とされ、学習と確かめの間を空ける gap も指定できます。分類ごとの行を日付の順に並べ、区切りを週の単位にそろえます。 公式のページは区切りの間隔がそろっていることを求めています。

件数に戻すときは、翌週の契約の数を掛けます。 翌週の契約の数は、直近の伸びをそのまま延ばして置きます。大きな販促の予定がある週は、営業の見込みの数を入れます。

出力形式を固定する

責任者とリーダーに渡すのは、次の表です。 木曜の朝の打合せで画面に映して見ることを前提にします。

【翌週の分類ごとの問い合わせの見込み（11月第3週・木曜 8:05 作成／取り込み 3:12）】

「印」と「案」で、責任者が見る先を決めます。 赤の日は、技術の応援を頼むかと、どの分類から担当を寄せるかを決めます。黄の日は、寄せるかどうかを決めます。 寄せる元の分類の残りが増えないかも、同じ表で確かめます。

表の一番下には、注意の印を並べます。 初めての規模のリリースには「リリースの上乗せ未定」、リリースの予定表の「画面が変わるか」が空の日には「リリースの項目が未入力」、取り込みが前日より古ければ「取り込みが止まっている」を出します。

機械で読む用には、同じ内容を CSV でも残します。 列は、日、分類、契約の数、率と件数の中央と上振れ、処理できる件数、残り、印、案、モデルを作った日付です。翌週に実績と並べて当たり方を見るのは、この CSV です。

システムへ連携する

Zendesk には読み取りしかしません。 取り込みに使う利用者の権限を読み取りに絞り、チケットの割り当てや状態を変える処理は作りません。 割り振りを変えるのは、リーダーが Zendesk の画面で行います。

人が確認する

1. 作った日時と取り込みの日時を見る … 表の上の2つの日時が当日の朝であることを確かめます
2. 赤と黄の分類を見る … 寄せる担当と、技術の応援を頼むかを決めます
3. 寄せる元の分類を確かめる … 寄せたあとに、寄せる元の残りが増えないかを表で見ます
4. 予測の外の事情を足し引きする … 大口の利用者の一斉の導入、法改正に伴う機能の変更、外部のサービスの仕様の変更などを足し引きします

目標は、20件をならして1件9分です。 印の無い分類は案を写すだけで、時間を使うのは赤と黄の分類と、リリースの週です。

例外に対処する

6行目は、運用を続けると必ず起きます。 「連携」を「API」と「外部のサービス」に分けた、といった変更で、過去の件数と新しい区分がつながらなくなります。 分類を変える前に、サポートの運用の責任者に知らせる決まりにします。

記録を残す

• 実行の日時、使ったモデルの作成日、最後に取り込みが成功した日時とカーソル
• 日ごと・分類ごとの率と件数の中央と上振れ、処理できる件数、残り、印、案
• 責任者とリーダーが決めた割り振りと応援の依頼と、案から変えた理由
• 翌週の実績（分類ごとの件数、初回の返信の目標を外した件数、日の終わりの残り）
• 月ごとの当たり方（分類ごとの中央の外れの大きさ、上振れを上回った日の割合）と、モデルの作り直しの結果

3つ目と4つ目を並べると、割り振りの判断が合っていたかが分かります。 赤の日に応援を頼み、目標を外した件数が出なかったなら、判断は働いています。印の無い日に目標を外したなら、処理の時間の表を見直します。