要点
サポート対応時間の計画は3つの決定で成り立ちます。どの時間帯とチャネルで対応するか、各時間に何人のエージェントが必要か、そして誰もいない時間に届いたチケットをどうするか、です。多くのチームは時計から考え始めます（「週末もやるべきか？」）。私ならチャネルから始めます。チャットの顧客が待てるのは数秒、メールの顧客は数時間であり、この違いひとつでスケジュールの大半が決まるからです。
採用する前に計算してください。ヘルプデスクの時間帯別チケットヒートマップを取り出し、件数に処理時間をかけ、そこに15〜35%のシュリンケージを上乗せします。これはZendesk自身のワークフォースマネジメントのドキュメントが業界標準としている範囲です。1つの席を24時間365日埋めるには約6人が必要で、小規模なチームが夜間を人手で埋めるべきでないのはそのためです。
人手で埋められない時間帯には、eeselのようなAIヘルプデスクチームメイトが、既存のヘルプデスク内で定型的なチケットに回答し、難しいものは朝に向けてタグを付けて残します。ライブチャット、電話、障害対応は人間が担当し、午前2時の「注文はどこ？」はAIが引き受けます。
サポート対応時間の計画とは？
サポート対応時間の計画とは、チームの稼働時間を、顧客が実際にあなたを必要とする時間に合わせる作業です。次の3つの問いに答えます。
- チャネルごとに、どの時間帯と曜日に対応するか？ メール、チャット、電話、SNSは同じ時間帯である必要はありません。
- 営業している各時間に、何人のエージェントが必要か？ 1日単位ではなく1時間単位です。件数は均一ではないからです。
- その時間外はどうなるか？ 自動返信、当番の担当者、パートナー、またはAIエージェントです。
私はeeselのサポートチームに所属しており、この計画の結果と毎日向き合っています。eeselは長年にわたりライブのサポートキューにAIを導入してきたため、多くのチームで同じパターンを見てきました。対応計画はチームが3人だった頃に勘で一度決められ、件数が3倍になっても誰も見直さなかった、というものです。
近い話題とも混同されがちです。対応時間の計画は、いつ営業するかを決めます。SLAポリシーは、その時間内にどれだけ速く返信を約束するかを決めます。シフトの引き継ぎは、その継ぎ目で起きることです。対応時間を誤れば、残りの2つでは救えません。
ステップ1：顧客が実際にいつ問い合わせてくるかを調べる
仮定ではなくデータから始めましょう。主要なヘルプデスクにはどれも、時間帯と曜日ごとのチケット件数を示すレポートがあり、読むのに10分ほどしかかかりません。
| ヘルプデスク | 開くレポート | 表示される内容 | プラン |
|---|---|---|---|
| Gorgias | Busiest times | 営業時間を示した時間×曜日のヒートマップ。作成、返信、クローズされたチケット | すべてのヘルプデスクプラン |
| Front | Workloadレポート、Busiest times | 新規会話、メッセージ、稼働中チームメイトのヒートマップ。デフォルトは9時〜17時で、24時間に拡張可能 | 現行のすべてのプラン |
| Help Scout | All Channelsレポート | 「Busiest time of day」ヒートマップとBusiest Day指標 | ドキュメントに記載なし |
| Freshdesk | Ticket volume trends（Load Analysis） | 時間別の作成、解決、再オープン、未解決のチケット | このレポートについては記載なし |
| Zendesk | Exploreレシピ、時間帯別のチケット | 「Ticket created - Hour」のカスタムレポートと、チャネル別の混雑時間のレシピ | Suite Professional以上、またはExplore Professional |
ヒートマップで見るべき点は2つあります。1つ目は当然ですが、濃いマスがどこにあるか。2つ目はより有用で、現在の営業時間外にある濃いマスです。Gorgiasのドキュメントは私より上手に言っています。「A dark cell outside your business hours is demand arriving when nobody is scheduled.」
次に、時間別の作成数と解決数を比べてください。作成数が上回る時間帯が、チケットの滞留の始まる場所だからです。FreshdeskのLoad Analysisはまさにこのための機能で、ドキュメントには、ある期間で作成数が解決数を上回るなら「you should add more agents during this time period.」とあります。
数日ではなく数か月分の履歴を使い、既知のピークはベースラインから除きます（Zendeskの予測は6か月分のチケットから始まります）。過去のチケットでeeselを学習させたある花のデリバリーブランドは、同じ理由でバレンタインデーと母の日のピークを除外するようeeselに依頼しました。ピーク週は、普通の火曜日がどんな日かを歪めてしまうのです。まずベースラインを計画し、ピークは別に計画します（ステップ6）。
ステップ2：時計ではなく、チャネルごとに対応範囲を決める
ここが私が最も強く押したい発想の転換です。「土曜日は営業するか？」は間違った問いです。正しい問いはこれです。このチャネルの顧客は、遅れが損失になるまでにどれだけ待てるか？
| チャネル | 顧客が待てる時間 | 対応範囲の意味 |
|---|---|---|
| 電話 | 数秒 | 回線に人がいるか、回線を閉じるか |
| ライブチャット | 1〜2分 | 人がオンラインにいるか、チャットを「メッセージを残す」に切り替える |
| メールとWebフォーム | 数時間 | 明示した時間内に誰かが返信する。翌朝からでもよい |
| SNSのDM | 数時間、ただし公開される | メールと同じだが、クレームにはより注意して目を配る |
| 障害とセキュリティの問題 | チャネルを問わず数分 | 他のすべてが閉まっていても、当番の担当者がいる |
Zendesk自身の予測エンジンもチャネルをこのように扱っています。予測のドキュメントによると、有人対応時間外に届いたメールの件数は「over the period of First Response Time」に分散されますが、時間外の音声とチャットの件数は繰り越されません。わかりやすく言えば、午後11時のメールは明日の仕事であり、不在着信は消えてしまいます。
これが、ほとんどのチームにとって妥当な初期設定になります。
- ライブチャネルは、きちんと人を配置できる時間帯だけ運用します。それ以外の時間はチャットをメール受付に切り替えます。Help Scout、Front、Zendeskはいずれも対応しており、Zendeskのオフラインメッセージのガイドで一つの設定例を紹介しています。
- メールには、24時間の人員ではなく返信の約束（「営業時間4時間以内」）を設定します。これが非同期サポートの核であり、SLAタイマーも同じスケジュールに従います。
- 障害には、毎日、名前の決まった当番を置き、短い連絡先リストを用意します。
Hacker Newsのコメント投稿者は、これを購入者側から指摘しました。SaaSについては「I'd be fine with business hour support. SaaS failures don't directly cost me money and/or reputation.」。あなたの顧客は違うかもしれません。決済製品や病院向けシステムは、この割り切りができません。自分たちがどちらなのか、正直に見極めてください。
ステップ3：各時間に必要なエージェント数を計算する
ここで計算です。簡単な版は、作業量モデルです。
配置するエージェント数 =（その時間のチケット数 × 1件あたりの分数 ÷ 60）÷ 稼働率 ÷（1 − シュリンケージ）
1件あたりの分数は平均処理時間です。他の2つの用語には定義が必要で、ZendeskのWFM用語集が明快な定義を載せています。
- 稼働率は、エージェントが業務対応に使う時間を総勤務時間で割ったものです。100%を保てる人はいません。Zendesk自身の計算例では90%が上限です。
- シュリンケージには「lunch breaks, training sessions, scheduled meetings」に加え、「absenteeism, holiday, vacation, sick days, lateness, and leaving early.」が含まれます。Zendeskは業界標準を**15〜35%**としています。
ここに自分の数字を入れてみてください。電卓は、ピーク時間に配置するエージェント数と、1週間の営業時間をカバーするのに必要な常勤人数を出します。
ライブチャネルでは、この作業量モデルは答えではなく下限です。チャットや電話の顧客は待ち行列に並びますが、ワークフォースツールがその待ち行列を見積もる計算式がErlang Cで、一定割合の問い合わせが目標時間内に応答されるよう、エージェントを上乗せします。Zendesk WFMは、必要人員を15分間隔ごとに「based on a modified version of Erlang C.」で算出します。
Erlang Cには、件数が少ないときの既知のくせがあります。Zendeskのベストプラクティス文書は、「for low-volume workstreams, the industry-standard Erlang C formula may result in slightly higher staffing recommendations.」と警告しています。同文書の計算例がその大きさを示しています。1日38件のメールが1件210秒なら処理は約2.2時間ですが、モデルは「1.5 agents per day」、つまり12時間分の有人対応時間にたどり着きます。この差は、閑散としたキューで素早い返信を保証するためのコストであり、閑散時間帯を人手で埋めるべきでないという最も強い論拠です。
24時間365日の席1つにかかる本当のコスト
「24時間365日にすべきか？」という議論の多くを終わらせる数字がこれです。
1週間は168時間です。Zendeskの用語集は、常勤1人を週40時間として数えます。誰も休暇を取らない前提でも、椅子1脚を埋め続けるのに4.2人です。ここにシュリンケージ30%を加えると、席1つで6人になります。夜間に2人欲しければ倍です。
これを経験したHacker Newsのコメント投稿者が、スプレッドシートが通常見落とすものをこうまとめています。
"Still need enough staff at each site to handle rotation for covering weekends and for people to go on holiday and get sick or quit for new jobs etc."
ステップ4：人手で埋められない時間帯の対応モデルを選ぶ
ピーク時間と人員数がわかったら、残りをどう扱うかを選びます。私が最もよく見る6つのモデルと、それぞれの代償は次のとおりです。
| モデル | 仕組み | 向いているケース | 落とし穴 |
|---|---|---|---|
| 営業時間のみ | 1つのスケジュール、明確な返信の約束、時間外は自動返信 | 遅れが顧客の金銭的損失にならないB2B SaaS | 月曜朝の滞留 |
| ずらしシフト | 開始時間を分散（7-15、9-17、11-19）して1チームで12時間をカバー | 同一地域で4人以上のチーム | 両端の手薄さ |
| オンコール当番 | 時間外の緊急対応用に1人が携帯電話やポケベルを持つ | 障害、VIPアカウント | 人が早く疲弊する |
| フォロー・ザ・サン | 2〜3地域のチームがそれぞれの日中を担当 | グローバルな顧客、エージェント15人以上 | 引き継ぎ、管理の二重化 |
| 時間外の外部委託 | パートナーが夜間と週末に対応（アウトソーシングガイド） | 電話が多く件数の多い一般消費者向けサポート | ナレッジ移管と品質 |
| AIが一次対応＋有人時間 | AIが定型チケットを24時間対応し、人間は勤務中に残りを担当 | 定型的な問い合わせの割合が大きいチーム | 良質なナレッジと明確な限界設定が必要 |
これを実際に経験したチームからのメモをいくつか。
オンコール当番はシフトより安く、見た目より高くつきます。 待機していると、静かな週でも生活が制約されます。
"We were a small team so rotation was weekly and you would be on support every 4 weeks or so. I couldn't go to the gym after work without worrying about a call coming in and ruined weekends for me."
ローテーションは本当の緊急時に限り、何が緊急にあたるかを短く文書化し、その裏に明確なエスカレーションプロセスを置いてください。
専任の採用は24時間365日より先で、その目安となるきっかけがあります。 ある創業者の経験則はこうです。チームがサポートに週20時間以上使っているなら、「hire a dedicated support person or agency, even if they're part time」し、そのうえで「schedule dedicated hours for each person to be on call.」。これがサポートチームの構成という問いの一文要約です。
日中の採用では夜間は解決しません。 10人のチームが急成長したという別のコメント投稿者は、専任のサポート担当を採用しても「after hours were an issue.」だったと述べています。空白が夜間にあるなら、日中の採用を増やしても埋まりません。
そこで出てくるのが、フォロー・ザ・サン型サポート、オフショアチーム、またはAIの一次対応です。オフショアチームのコストとAIの比較は別記事にまとめています。
ステップ5：スケジュールを作り、ヘルプデスクを設定する
スプレッドシートの中にしかない計画は、1か月で現実からずれていきます。タイマー、ルーティング、自動返信が従うよう、ヘルプデスクに入れてください。各製品でできることと、プランによる制限は次のとおりです。
| 営業時間 | 複数のスケジュール（地域、チャネル） | エージェントのステータスを切り替えるシフト | |
|---|---|---|---|
| Zendesk | Suite GrowthとProfessionalでは1つのスケジュール | Enterprise（スケジュールのドキュメント） | ネイティブ非対応。WFMアドオンが必要 |
| Freshdesk | Growth以上 | Pro（年払いで$55/エージェント/月） | Enterprise（$89）、Agent Shifts |
| Help Scout | Plus（$45）以上、受信箱ごと | 受信箱ごと、Plus以上 | 利用不可 |
| Gorgias | Basic以上、連携ごと | 連携ごと | 利用不可 |
| Front | Professional（$65）、受信箱ごと | 受信箱ごと | Enterprise（$105）、Shifts |
落とし穴はステータスです。Zendeskのエージェントステータスのドキュメントには「operating hours won't set an agent's status」とあり、スケジュールが「閉」でも、オフラインにし忘れた人へのルーティングは止まりません。まずここを直してください。インテリジェントルーティングは、読み取るステータスの質に左右されるからです。
Zendeskの営業時間と祝日スケジュールのガイドで設定方法を説明しており、時間外の自動化で、その時間外に届いたチケットの扱いを処理できます。
Gorgiasでは、スケジュール設定した自動応答が同じ役割を果たします。
ワークフォースマネジメントソフトを導入するタイミング
6人のチームの対応時間を計画するのに、ワークフォースマネジメント（WFM）ツールは要りません。シフトとチャネルをまたいで数十人を配置するようになったら必要です。ツールが時間帯別の予測を行い、スケジュールを作ってくれるからです。
- Zendesk WFMは、チケット履歴（最低1か月分のデータが必要）から「for up to a year in the future」の件数を予測し、15分間隔ごとの必要人員を示します。公開価格は、WFMとQAをセットにしたWorkforce Engagement Bundleで、年払いでエージェント1人あたり月
$50です（Zendeskの料金ページ）。アドオンはアカウント内の全エージェント分を購入します。 - Assembledは、料金ページでWorkforce ManagementをCore、Pro、Enterpriseの各ティアで月
$25、$45、$75と掲載していますが、エージェント単位かどうかは明記していません。WFMのページは、人員計画が「account for AI agent capacity alongside human resources」と述べており、これは正しい考え方です。
ステップ6：ピーク、祝日、休暇に備える
ベースラインの計画は通常の1週間をカバーします。それを崩すものが3つあります。
季節的なピーク。 ECのチームは自分たちのピークを知っています。ブラックフライデー、祝日、ローンチ週などです。eeselに相談に来たあるサプリメントブランドは月に約7,000件のチケットを扱い、11月から5月が繁忙期で、チームだけでは件数をさばけませんでした。ピーク時の対応は別のレイヤーとして計画します。臨時スタッフ、残業、あるいはチケットのデフレクションで繰り返しの多い部分をAIエージェントに任せる方法です。ブラックフライデーのサポートのガイドで進め方を紹介しています。
祝日。 対応している全地域のすべての祝日をヘルプデスクのスケジュールに追加し、SLAの時計が止まり、自動返信が正しい内容になるようにします。そのうえで、それぞれの翌日を確認してください。たいてい、その月で最悪の日です。
休暇と離職。 これもシュリンケージの話で、計画が静かに破綻するのはここです。6人のチームで2人が同時に休むと、能力は3分の1減ります。ベテランを失うとさらに痛手です。知識も一緒に去るからです。あるIT サービス会社は、退職する2人のシニアエージェントの知識を、去る前に取り込むためにeeselを訪れました。回答をナレッジベースに書き残すことも対応時間の計画の一部です。
サポート対応計画のどこにAIが入るか
ここで計画が安くなります。6人で夜間の席1つを埋めるのなら、多くのチームにとっての問いは「夜間をどう人手で埋めるか」ではなく、「夜間のうち本当に人が必要なのはどれだけか」です。ほとんどのキューでは、答えは思うより少なく、それが時間外のAIサポートを支持するすべての理由です。
うまくいく形はこうです。チームが平日の忙しい時間を担当し、AIエージェントがそれ以外のすべてを一次対応として担当し、1人が障害用に待機し、AIが確信を持てないものは、タグ付けと要約をして次の有人シフトまで待ちます。AIが埋めるのは空きのマスで、忙しいマスではありません。
Anytime Fitnessは、私が示せる最も分かりやすい例です。eesel導入前は、午後10時に質問した会員は朝まで待たされていました。今では、5,000以上のジムで、よくある質問にどの時間帯でも答えています。Gridwiseでは、eeselのAIヘルプデスクエージェントページに載った同社のコメントによれば、最初の1か月でティア1チケットの73%をeeselが解決しました。
時間外のAIを安全にするルールは、ほぼすべての商談で購入者が求めるものです。Gorgiasを使うサプリメントブランドのCX責任者は、月約7,000件のチケットを扱っており、こう率直に述べました。
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
これが対応計画の縮図です。AIは夜間に確信を持てる部分を引き受け、残りは文脈を添えて朝のキューに届きます。同じ考え方がAIによる24時間365日サポートを支えています。仕組みを知りたければ、AIが人に引き継ぐべきタイミングのガイドで説明しています。
eeselが痛い目に遭って学んだ教訓がひとつあります。営業時間と引き継ぎルールは、AIへの指示だけでなく、ヘルプデスク自体のスケジュールとルーティングの設定に置いてください。あるお客様のAIは、詳しいプロンプトの指示があったにもかかわらず、タイムゾーンのロジックを誤りました。正とすべきはヘルプデスクのスケジュールで、AIはそこから読み取るべきです。
サポート対応時間の計画でよくある間違い
- 1時間ではなく1日で計画する。 月曜に「人員が十分」なチームでも、午前9時から11時は溺れることがあります。ヒートマップを使ってください。
- シュリンケージを忘れる。 シュリンケージ0の計画は、毎週人手不足です。自分の数字がわからなければ30%から始めてください。
- すべてのチャネルで同じ時間にする。 人を置けない時間にライブチャットを開けると、良いメール体験が悪いチャット体験に変わります。人員不足にするより先にチャットを閉じてください。チャットボットとライブチャットは別記事で比較しています。
- 閑散時間帯を人で埋める。 Erlang Cは件数の少ない間隔を水増しし、夜間はほとんどが少件数です。購入できる最も高い対応体制です。
- 障害の担当者がいない。 どの計画にも、待てない事態のための名前の決まった当番が必要です。他がすべて閉まっていてもです。
- 計画を見直さない。 四半期ごと、そして大きなローンチの後に、他のカスタマーサービスKPIと並べてヒートマップを取り直してください。初回応答時間を時間帯別に追い、ある時間帯で急上昇したら、そこが次の空白です。
サポート対応時間の計画にeeselを
eeselのAIヘルプデスクチームメイトは、人手で埋めるには高すぎる対応計画のマスを埋めます。Zendesk、Freshdesk、Gorgias、Help Scout、Frontなど、すでにお使いのヘルプデスクに参加し、過去のチケット、ヘルプセンター、マクロから学習して、夜間と週末の定型的なチケットに回答します。確信を持てないものは、次のシフト向けの要約を付けてキューに残します。
実際のチケットに触れる前に、過去の数百件のチケットで試せるので、時間外の件数のうち何割を処理できたのかがはっきりわかります。夜勤のために席を増やす必要もありません。Teammateプランは月$299から500クレジットで、チケット1件またはチャット1回が1クレジットです。
ヒートマップの午後6時以降に濃いマスがあり、それを埋めるために6人を採用したくないなら、ご自身のキューでeeselを無料で試し、先週末に何に回答できたかを確認してください。