要点
ホリデーシーズンのボリュームは、怖い週末が1回あるだけではありません。ブラックフライデー（2026年11月27日）から始まり、12月第1週にピークを迎え、1月の返品の波で終わる6週間の季節的な波です。チケットが2倍になっても、エージェントを2倍にする必要はありません。昨年の日別ボリュームから予測を立て、定型的な注文・ポリシーの質問はAIに完全に解決させ、残りの分だけ人を採用または手配します。
次の5つを、この順番で行います。日別・トピック別の予測、チケットの3レーンへの振り分け、人のレーンだけへの人員配置、滞留を隠さない休業時間の設定、そして毎日15分のチェックです。キューがZendesk、Gorgias、Freshdeskにあるなら、eeselのようなAIヘルプデスクのチームメイトがそのキューに参加し、「注文はどこ？」や返品ポリシーのチケットに回答し、残りには下書きを残します。RúngneのGorgiasキューは1か月の間に週およそ300件から780件まで変動しましたが、3エージェント構成のeeselがタグ付け、下書き、直接回答を担当しています。
まずホリデーシーズンの人員ギャップを見積もる
計画を立てる前に、まず数字が欲しいところです。通常の週のチケット数、昨年12月に見た倍率、AIが完全に解決できるキューの割合を入力してください。この計算ツールは、Zendesk自身の人員配置モデルと同じ要素であるシュリンケージと稼働率を使うので、「チケット数÷エージェント数」の推測より実際のシフト表に近い答えが出ます。
ご自身の数字を入力すると、AIありとAIなしでピーク週に必要なエージェント数がわかります。「完全に解決」とは、ボットが返信したことではなく、お客様の問題が解決したことを指します。
読み方について2点あります。まず、40%は注文状況やポリシーの質問が多いEC向けキューの出発点となる仮の値です。実際の数字はベンダーのスライドではなく、自社のチケットで行うパイロットから得てください。次に、出力は生産的なエージェントの人数なので、追加3.5人という結果は、トレーニング時間と休暇を加味すると通常は5〜6人の臨時スタッフを意味します。
なぜ急増は週末ではなく「シーズン」なのか
多くのチームはブラックフライデーに備えますが、12月に不意を突かれます。Shopifyのホリデーサービスガイドによると、週ごとのチケット数はクリスマス後の週を除いて12月いっぱい平均を上回り、1月上旬にも再び増えてから落ち着きます。また、Shopifyは12月第1週を、BFCMのプロモーション直後の時期としています。この形こそが「週末の作戦室」が失敗する理由です。チームは11月27日から30日にエネルギーを使い果たし、そのあとさらに1か月同じペースを保たなければなりません。
私はeeselのサポートチームでキューを担当していますが、ECの導入で気づくパターンは、ピーク後のチケットのほうがピーク中のものより難しいということです。序盤は「注文はどこ？」や「このコードは併用できる？」です。12月中旬には「ギフトに間に合わなかった」となり、1月には返品、交換、返金トラブルになります。最初の急増だけでなく、全体の流れに合わせて人員を計画してください。
ステップ1：昨年のデータから日別・トピック別に予測する
昨年の10月から1月までのチケットを引き出し、月別ではなく日別にグラフ化します。月次の合計では、実際にチームを追い詰める2〜3日が見えなくなります。そのうえで各日をトピック別（注文状況、返品、商品に関する質問、支払いの問題）に分けます。2倍になった日と、それを押し上げたトピックを探します。
Zendeskをお使いなら、Workforce Managementアドオンがこれを代行してくれます。予測にはProphetアルゴリズムが使われ、最低1か月の履歴が必要で、最大2年分を読み込みます。必要人員表は15分間隔で、修正版Erlang Cモデルに基づきます。入力は上の計算ツールと同じで、平均対応時間、稼働率、シュリンケージ、最小人員です。Zendesk自身の計算例ではシュリンケージ30%、最大稼働率90%を使っているため、本ツールの初期値もそれに合わせました。
元コールセンター勤務の人が、人員配置を平均に合わせたときに何が起こるかを説明しています。
"The problem with it as that you've built in very little cushion for when calls are above that average, so a customer's experience is nearly always going to be either wait an average amount of time, or wait an above average amount of time."
アドオンがなくても、価値の80%は得られます。昨年の日別件数、トピックごとの倍率、トピックごとの平均対応時間をまとめたスプレッドシートがあれば、根拠のある幅を出せます。見落とされがちなのは、その幅を「想定」「高め」「すべてが悪い方向に行った場合」の3つのシナリオとして書き出し、それぞれにトリガーを決めておくことです。11月第2週が計画より20%多ければ、滞留が出てからではなく、その日のうちに高めのシナリオに切り替えます。人員計算の詳細はサポートのカバレッジ計画で解説しています。
ステップ2：チケットを3つのレーンに分ける
計算ツールで最も効くのは、人に届かないチケットの割合です。Shopifyは典型的な質問を挙げています。注文はいつ届くか、どう返品するか、プロモーションコードはどこに入力するか、配送先住所は変更できるか、自分の国に配送しているか。どれも答えやすく、Shopifyの言葉を借りれば、エージェントが難しい問題に使うべき余力を食いつぶします。
私はキューを3つのレーンに分け、シーズン前にそれぞれのルールを書き出します。
- AIが単独で回答。注文状況、配送時間、返品ポリシー、プロモーションコードのルール、購入前の質問。答えがストアのデータやヘルプセンターにあり、誤答しても訂正のコストが小さいものです。
- **AIが下書きし、人が送信。**住所変更、破損品、承認上限未満の金銭に関わるもの。エージェントは返信を一から書く代わりに、できあがった返信を確認します。
- **人のみ。**怒っているお客様、不正の疑い、VIP、チャージバック、法的・安全面に関わるもの。AIが勝手に対応せず引き継ぐよう、エスカレーションルールを文書にしてください。
実際のキューでの様子を見てみましょう。ノルウェーのクライミングアパレルブランドRúngneはGorgiasを使い、1か月に約2,100件、週にして約300〜780件のチケットを処理しました。eeselの構成は、1つの役割ずつを持つ3つのエージェントです。1つはすべてのチケットを受領してタグ付けし、1つはShopifyの注文・在庫データを確認して内部メモとして下書きを残し、1つはポリシー、追跡、在庫など、チームが選んだトピックにだけ回答します。およそ7件に1件はeeselが単独で回答し、キャンセル、破損品、荷物の紛失は常にチームに回されました。トピックを「下書き」から「単独で回答」に移すのはリストの編集だけなので、12月第1週に欲しいのはまさにこのつまみです。
Question BeautyはGorgiasとShopifyで、もう一方の端にあたる運用をしています。ある月、eeselは約960件のチケットに直接返信し、配送の質問に答える前に約290件のShopify注文を確認し、人を介さず約280件のチケットを完了しました。返金、クレーム、卸売の依頼は、メモ付きで人に回されました。レーンは同じで、つまみの設定が違うだけです。
ここで大事な定義があります。AIが解決したと数えるのは、問題が実際に解決した場合だけです。ボットが回答しても、2時間後にお客様が怒って再度連絡してくるなら、そのチケットは手間が増えただけの人の仕事です。どのトピックがどのレーンに本当に属するかは、封じ込め率の測定とローンチ前のテストで確かめます。昨年12月のチケットをAIに再生してみるのは、10月にできる最も安上がりなリハーサルです。
ステップ3：人が対応する部分に人員を配置する
AIのレーンを引くと、計算ツールは人の不足分を示します。それを3つの供給源から、次の順で埋めます。自チームの追加時間と他部署から応援できる人、臨時または外部委託のエージェント、そして最悪の日のための余力の取り決めです。
落とし穴はタイミングです。Shopifyのガイドは、繁忙期が来てからでは追加エージェントを戦力化するのに間に合わないかもしれないと警告しており、早めの判断が必要です。もう1つ有用な事例も報告されています。Boll & Branchは、外部委託のエージェントに簡単なチケットをさばいてもらい、最新の商品情報に詳しい社内チームが難しいチケットに時間を使えるようにしたほうがよいと気づきました。これは上のレーンと一致します。臨時スタッフはレーン1とレーン2の確認部分を担当し、最も優秀な人はレーン3を担当します。
臨時スタッフのための実践ルールが3つあります。
- **レーン1だけを教える。**ヘルプセンター全体ではなく、8〜10個のマクロと返品ポリシーを渡します。何を削るかは季節スタッフのオンボーディングで解説しています。
- **11月上旬までにマクロとポリシーを凍結する。**12月第2週にポリシーを変えると、全員の再トレーニングが必要になります。ポリシー変更管理を参照してください。
- **立ち上がり期間を見込む。**新人は初日からフルスピードではありません。「追加3.5人」という結果を6人の採用に変えるのが立ち上がり期間という数字です。
シーズン中の外部委託チームを検討するなら、先ほど測った不足分のコストと比べてください。代表的な選択肢はECサポートの外部委託と外部委託コストで解説しています。ヘルプデスクの中で作業するチームにキュー全体を任せたいなら、eeselのManaged Supportは月額$5,000の定額で、創業期限定の提供です。ただし、ここで扱っている人員配置の問題とは別の判断になります。
季節スタッフの内側からの声も同じ話をしています。ある小売の在宅勤務プログラムの元研修生は、研修の不足をこう述べています。
"You will be pushed onto calls without shadowing or seeing how to do the job before actually doing it."
コールセンターのベテランは、そもそもなぜ不足が生まれるのかを説明しています。
"Unlike sales, support agents cost money but don't generate any, so there can be a tendency to under-hire. Turnover can be pretty high, and it takes time to get new hires trained before they can start answering calls."
ステップ4：滞留を隠さずに休業時間を設定する
休業時間の設定は事務作業に見えますが、最も気づかれにくい悪影響が出る場所です。主要なヘルプデスクはどれも、休日を営業時間外として扱い、営業時間ベースの指標はその時間を数えません。
Zendeskでは、休日はスケジュールの例外として設定します。最大2年先まで好きなだけ追加でき、営業時間外として扱われ、営業時間で測る指標にはカウントされません。また、半日だけの休日は設定できないため、クリスマスイブの半日勤務には別の方法が必要です。スケジュール機能にはProfessionalまたはEnterpriseのSupportプランが必要で、複数のスケジュールを設定できるのはEnterpriseだけです。
Gorgiasも同様ですが、便利な追加機能があります。営業時間と休業時間は、営業時間の条件を持つルールが実行されるか、SLAタイマーがいつ止まるか、通話がどうルーティングされるかを決めます。休業時間ではヘルプデスクを1日閉じることも、短縮することもでき、その日は割り当てたすべてのインテグレーションの通常営業時間に代わって適用されます。Freshdeskでは、営業時間カレンダーに入れた休日は非稼働日になります。
その結果は見落としやすいものです。休業中はクロックが止まるため、12月24日に連絡したお客様はまだ待っているのに、初回応答レポートは問題なさそうに見えます。2つの習慣で防げます。
- **SLA指標だけでなく、実際の待ち時間を追う。**11月15日から1月15日までの暦時間ベースのレポートを1つ、営業時間ベースのレポートの隣に置いてください。暦時間での初回応答時間が、お客様が実際に感じる待ち時間です。
- **正直な自動返信を送る。**Gorgiasには「休業時間中」というルール条件があり、その自動返信のベストプラクティスは、休業時間を事前にスケジュールし、チームがいつ戻るかを書いた返信を送ることを勧めています。通常の時間外ルールに「休業時間外」の条件を加えれば、お客様に2通届くことを避けられます。
ホリデー期間中もチームをオンラインに残すなら、人が休んでいる間にレーン1を動かし続ける定番の方法がAIによる時間外サポートです。同じ理由で、ZendeskのSLAポリシーとFreshdeskのSLA設定も見直す価値があります。
ステップ5：毎日の作戦室を運営する
ブラックフライデーの前の週から1月第1週まで、毎朝と毎夕に15分のチェックを行うのがおすすめです。毎回同じ5つの数字を1枚にまとめます。
- **滞留の件数と経過時間。**平均より、最も古い未対応チケットのほうが重要です。新しいチケットのチケット滞留は問題ありませんが、3日経ったチケットの滞留は問題です。
- **暦時間での初回応答。**一時停止された数字ではなく、ステップ4の数字です。
- **AIの封じ込め率と再オープン率。**再オープンが増えているなら、レーン1のトピックが漏れています。レーン2に移してください。
- **今日の上位3トピック。**配送業者の遅延や使えないコードなど新しいトピックが出たら、すぐにマクロ1つとヘルプセンターの1行を書きます。
- **エージェントの負荷。**稼働率の上限を超えているのは誰か、余力を引き受けられるのは誰か。
トリアージのルールは人にとっても助けになります。返金、VIP、チャージバックを最優先にし、次に配送締め切りに間に合わなくなりそうな注文、その後はそれ以外を古い順に並べます。誰が何を担当するかの仕組みは、共有キューの管理とオーバーフロー管理で解説しています。
臨時スタッフは、人手以外にも中核チームの休息という価値をもたらします。繁忙期の休暇に関するあるスレッドは、こううまく表現していました。
"Getting some rest during a busy period is the best way to ensure that people won't get burned out."
Shopifyのガイドには、取り入れたい点がもう1つあります。ボットや自動返信を使うときは、メッセージが自動であることをお客様に伝え、ボットがどう回答したかを人が確認することです。自動返信は、チケットを閉じるものではなく、会話の始まりとして扱いましょう。
2026年の準備タイムライン
今年のブラックフライデーは11月27日、サイバーマンデーは11月30日なので、作業カレンダーは次のようになります。
| 時期 | 完了させること | 詳しくはこちら |
|---|---|---|
| 10月中旬 | 日別・トピック別に予測し、3つのシナリオを決め、計算ツールを実行する | カバレッジ計画 |
| 10月下旬 | 臨時スタッフか外部委託かを決め、昨年12月をAIで再生する | AIのテスト |
| 11月上旬 | 臨時スタッフにレーン1を教え、マクロとポリシーを凍結し、休業時間をスケジュールする | 季節スタッフのオンボーディング |
| 11月23日〜30日 | 作戦室を稼働し、毎日5つの数字をチェックする | ブラックフライデーのメッセージ |
| 12月 | 人員体制を維持し、配送締め切りに関するトピックを注視する | SLA管理 |
| 1月 | 返品の波に対応し、翌年のために書面で振り返る | 返品の自動化 |
よくある失敗
- **週末だけを前提に人員を配置する。**計算ツールのピーク週だけが忙しいわけではないので、12月と1月も別々に確認してください。
- **触れただけのチケットを解決済みと数える。**計算ツールでAIの解決率を水増しすると、現場での実際の人手不足になります。
- **臨時スタッフにすべてを教える。**広くより狭く。レーン1だけです。
- **返信なしで休業にする。**無視されたお客様は再度連絡してきて、重複はすべてチケットになります。
- **シーズン中にポリシーを変える。**AI、マクロ、臨時スタッフのすべてが古いルールを覚えてしまいます。
- **振り返りをしない。**来年の予測は今年のデータなので、毎日の数字を保存しておきましょう。
ホリデーシーズンのボリュームにeeselを試す
キューがZendesk、Gorgias、Freshdeskにあるなら、11月までにレーン1を縮める最短の方法は、AIヘルプデスクのチームメイトを迎え、定型的なチケットはAIに任せて、人は難しいものに集中することです。eeselは既存のヘルプデスクの中で動作し、ヘルプセンター、マクロ、過去のチケットから学習し、単独で回答させる前に内部メモとして返信を下書きできます。
料金はeeselの料金ページにある固定のクレジットプランです。チケット1件またはチャット1件が1クレジットで、Teammateプランは500クレジットの月額$299から、5,000クレジットの月額$1,749まで用意され、プランの規模はいつでも変更できるため、季節的なピークに向いています。eeselを試すなら、100クレジットが無料で付くので、ブラックフライデーの前に昨年12月のチケットを再生してみてください。