← エピソード一覧に戻る Episode 256 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
皆さんこんにちは、タカシです。今日は SaaSサポートのキャパシティ計画です。Zendesk の事例では、225人のエージェントが年 300万件の問い合わせに向き合う一方、処理能力は約 224万件。つまり人数がいても、設計が甘いと最初から詰まるんです。
ミカ
うわ、それは衝撃ですね。人が足りないというより、需要と供給の計算が合っていない感じですね。採用を急げば済む話にも見えますけど、SaaS だともっと複雑そうです。
タカシ
その通りです。キャパシティ計画は、何人雇うかだけではありません。問い合わせ量、SLA、時間帯、地域、AI、自動化、教育時間まで含めて、いつどこに何人分の処理能力を置くかを設計する経営テーマなんですね。
ミカ
なるほど。サポート部門のシフト表づくりというより、継続売上を守るための供給計画なんですね。まず何から見ればいいんでしょうか。問い合わせ件数だけでは足りなさそうです。
Chapter 2 需要予測と供給能力の見方
タカシ
最初は需要予測です。Zendesk WFM は最低 1カ月、最大 2年の履歴から将来の volume と必要 FTE を予測します。しかもマーケ施策や機能終了、障害のような特殊イベントは volume adjustment や outlier 除外で直す前提です。
ミカ
ここ大事ですね。月平均で今月は一日何件です、と見ているだけだと、請求日やリリース日や月曜朝の山が消えてしまう。現場は特定の時間帯だけ毎週燃えているのに、経営会議では平穏に見えるわけだ。
タカシ
次に supply 側です。在籍人数をそのまま処理能力に置くのが典型的な誤りです。Assembled は modern omni-channel なら shrinkage を 10から15パーセント、高度な digital-first 環境では 15パーセント超で見る目安を出しています。Zendesk でも業界標準は 15から35パーセントです。
ミカ
つまり、名簿に 10人いても 10人分は動かないんですね。会議、研修、欠勤、休暇、新人の立ち上がりまで含めると、実際に顧客対応へ出せる時間はかなり減る。ここを甘く置くと、最初から赤字予算みたいな計画になりそうです。
Chapter 3 AI時代のキャパシティ計画
タカシ
2026年の難しさはここからです。Intercom は AI-first の capacity planning で automation rate を重視しています。AI が何件関与し、そのうち何件を解決したか。この値を inbound volume、human output、occupancy と並べて見るべきだとしています。
ミカ
AI が入ると、つい問い合わせが減るから人も減らせると思いがちですけど、そこが罠なんですね。簡単な問い合わせを AI が吸うほど、人に残る案件はむしろ重くなりそうです。
タカシ
まさにそこです。Intercom は、AI が進むほど人間の cases closed は下がる前提で置くほうが安全だと言っています。残る仕事が複雑になるうえ、AI の回答レビュー、ナレッジ更新、改善提案といった off-the-queue の仕事も増えるからです。
ミカ
なるほど、AI は余剰人員を作る装置じゃなくて、仕事の中身を変える装置なんですね。問い合わせ対応だけ見ていると、人の本当の負荷を見誤る。経営者がここを理解していないと、現場に無理が乗りそうです。
Chapter 4 具体例で見る設計の差
タカシ
良い例として Smartly があります。Intercom の事例では、automation と analytics を使い、スキルの違うメンバーを時間帯ごとに最適配置して、サポートキャパシティを 50パーセント拡大しつつ、運営コストを 30パーセント削減しました。chat の 10パーセントは自動クローズです。
ミカ
すごいですね。単に人を増やしたのではなく、時間帯とスキルで配置を組み直し、自動化できるところは先に閉じている。初回応答 3分未満、調査時間 90分、CSAT 97パーセント以上まで維持しているのが説得力あります。
タカシ
公開運営の GitLab も面白いです。SLA 達成が不安定なとき、対策として ticket の SLA breach が多い時間帯への focused staffing と、顧客の preferred timezone に合わせた workflow 調整を挙げています。総人数より、穴のある時間帯を埋める発想ですね。
ミカ
ここ、SaaS っぽいですね。日本時間の昼に人が足りていても、EMEA の朝や米国午後に薄ければ SLA は落ちる。キャパシティ計画って年次採用の話だけじゃなく、地域と時間帯の地図を描く仕事なんだなと分かります。
Chapter 5 失敗を避ける実務
タカシ
よくある失敗は五つあります。平均値でしか見ない、shrinkage を甘く置く、全員を同じ一人として扱う、AI を削減枠としてしか見ない、そして予測外れ時の flex plan がない。このどれか一つでもあると、繁忙で一気に崩れます。
ミカ
採用が決まっても、実際に戦力になるまでは時間がかかりますもんね。SLA が落ちてから募集を出すのでは遅いし、BPO や他部門応援の発動条件がないと、毎回その場しのぎになりそうです。
タカシ
明日からやるなら、需要予測をチャネル、キュー、契約プラン、地域、15分から30分単位で持つこと。次に productive hours で capacity を置くこと。さらに automation rate、output per person、occupancy、backlog、SLA を週次で見直し、役割別の供給枠を分けて管理することです。
ミカ
今日は SaaSサポートのキャパシティ計画を見てきました。人数を増やす前に、需要の山、実際に出せる時間、AI で変わる仕事、そして時間帯ごとの穴を見抜く。ぜひ皆さんの組織でも、 headcount ではなく供給能力を設計する視点で見直してみてください。