要点
サポート担当者の立ち上がり期間とは、新人が助けなしで、チームの速度と品質でキューを処理できるようになるまでの期間です。ほとんどのチームは最初のゴール、つまり最初の単独対応チケットしか測っていません。本当のゴールは、先輩がそばにいなくてもチーム中央値の品質に達することで、私が読んだスレッドでは6週間から6か月かかっています。
ヘルプデスクの担当者別レポートを使い、各担当者の開始日から週ごとに追跡します。私が確認した5つのヘルプデスクのどれにも、「新人」や在籍期間のフィルターはないため、曲線は自分で作ることになります。
短縮するには、立ち上がりを2つの山に分けます。調べる時間（マクロ、ポリシー、過去の回答を探す時間）は、良いツールで縮まります。たとえば、過去のチケットから返信案を作り、新人が確認するAIヘルプデスクチームメイトです。判断力（トーン、例外対応、エスカレーションの見極め）は、実際のチケットでの経験と週次のコーチングでしか縮みません。
サポート担当者の立ち上がり期間とは？
立ち上がり期間とは、担当者の初日から、ほかのメンバーと同じようにキューを処理できるようになる日までの期間です。私はeeselのサポートチームで毎日キューを担当していますが、チームが新人が「立ち上がった」と言うとき、実は3つの異なることを指していることが多いと感じています。
- 最初の単独チケット。 見学をやめ、自分で顧客に返信した。
- チーム中央値のボリューム。 1週間に閉じるチケット数が一般的な担当者並みになった。
- チーム中央値の品質、助けなし。 QAスコア、再オープン率、CSATがチームと同水準になり、3件に1件の頻度で先輩に声をかけることもなくなった。
最初の2つは到達しやすく、ごまかしもききます。新人は最も簡単なチケットだけを選んだり、先輩に何を書けばいいか聞いて答えを貼り付けたりして、多くのチケットを閉じることができます。だから私は3つ目の旗だけを立ち上がりの終わりと数えます。顧客にとっても、これまで黙って2人分の仕事をしてきた先輩にとっても、重要なのはこの旗です。
オンボーディング計画そのものを作るなら、同僚のサポート担当者向けトレーニングソフトウェアのガイドが各段階のツールを扱っています。この記事は時計の話です。どれくらい進むのか、どう読むのか、どう短くするのかを扱います。
サポート担当者の立ち上がりにはどれくらいかかる？
信頼できる業界の公式ベンチマークはありません。探しましたが、立ち上がり期間の正式な定義を公開しているヘルプデスクやQAベンダーは確認した範囲ではありませんでした。最も近いのはMaestroQAの用語集（同社は現在Rippit名義）で、サポートのオンボーディングは「typically run(s) from 2-8 weeks」としています。ClassPassの顧客事例では、新人は在籍「the first 60 days」の間、追加のQAが行われました。
実際の担当者やチームリーダーが語る期間はもっと長く、数字ではなく幅があります。
| 環境 | 報告されている内容 | 出典 |
|---|---|---|
| コールセンター、大量処理 | 研修6週間、ネスティング6週間、その後3か月で指標目標を33%、66%、100%と引き上げ | r/callcentres |
| コールセンター | 座学4-6週間、ベテランと通話に同席1-2週間、90日でレビュー | r/callcentres |
| 電話サポート | 研修1週間、1か月目に25件のミス、3か月目以降はミスゼロ | r/callcentres |
| MSPのヘルプデスク | 導入研修、見学、低優先度チケットを2か月、3か月目にオンコール | r/msp |
| 技術サポート | 3-6か月後に最も難しいケース以外は対応可能 | Hacker News |
| クラウドサポートエンジニア | 最初の3か月はケースを担当しながら研修 | Hacker News |
2つのパターンが目立ちます。1つ目は、「キューに入ってよい」と「キューで優秀」の間には、たいてい日数ではなく月数の差があることです。r/callcentresのスレッドで、スコアカード80%に届かなかったために研修クラス全員が解雇された後、あるチームリーダーはこうはっきり述べています。
"Some of our best agents are shaky for the first few months before their performance skyrockets. 10 days is nothing."
2つ目は、製品の複雑さが下限を決めることです。ネットショップの返品・配送のキューは、質問の種類が少なくて済みます。B2B SaaSやITのキューは種類が多く、新人は何か月も初見の質問に出会い続けます。r/sysadminのヘルプデスクリーダーは、経験者の新人が1か月の研修期間を経ても4か月目で「about 50/50」に見えると書いていました。同じスレッドの別の返信です。
"First month or 2 are there for ironing out the overwhelming feeling. The 6 month review is common for a reason."
したがって、役に立つ基準は自社の数字です。直近3人が3つ目の旗に12週間かかったなら、それが基準線で、目標は次の1人を9週間にすることです。
ヘルプデスクで立ち上がり期間をどう測る？
ここに落とし穴があります。私が確認した5つのヘルプデスクのどれも、レポートのドキュメントに担当者の開始日、在籍期間フィールド、「新人」グループがありません。ただし、どれにも、立ち上がり曲線を手作業で作るのに必要な2つの機能、担当者別フィルターと任意の期間指定はあります。方法は、新人ごとに週次のスナップショットを取り、チーム中央値と比較することです。
私は4つの数字を追跡します。それぞれが、立ち上がっていないのに立ち上がったように見える別のパターンを捕まえるからです。
- QAスコア。 品質のチェック。品質保証スコアカードが出す値を毎週。
- 対応時間。 速度のチェック。平均対応時間、またはヘルプデスクが報告する最も近い指標。
- 再オープン率。 「本当に解決したか」のチェック。早く閉じても戻ってくるものは数えません。
- 助けを求めた回数。 自立度のチェック。新人が先輩にタグ付けした社内メモやSlackスレッドを数えます。
私の目安は次のとおりです。4つすべてが3週連続でチーム中央値の約90%以内に収まったら、立ち上がったとみなす。3週間とするのは、たまたま良かった1週間をカウントしないためです。100%ではなく90%なのは、チーム中央値に最も優秀な人も含まれているからです。
各ヘルプデスクで数字がある場所
| ヘルプデスク | 担当者別レポート | 担当者フィルターと期間指定 | 知っておくべきプランの制限 | 担当者別の品質スコア |
|---|---|---|---|---|
| Zendesk | Supportダッシュボード：Assignee activityとAgent updates | あり、両方 | Suite Professional、年払いで担当者1人あたり月$115（料金） | Zendesk QAのIQSとAQS。QAまたはWEMアドオン経由（WEMバンドルは担当者1人あたり月$50） |
| Freshdesk | Agent Performance Report、全プラン | あり | Pro、年払いで担当者1人あたり月$55（プラン表） | アナリティクスのドキュメントには記載なし |
| Gorgias | Agents performance report、全Helpdeskプラン | 担当者またはチーム、プリセットとカスタム期間 | レポートは全Helpdeskプランで利用可能 | Auto QA、AI Agentのサブスクリプションが必要 |
| Help Scout | Company and User report、Happiness | ユーザー別ドリルダウン、TeamsはPlusとPro | Standardは2年分のデータを保持、PlusとProは全期間 | ユーザーごとのHappiness Score |
| Front | Team performance report | チームメイトのフィルター、カスタム期間 | Starterは6か月、Professionalは24か月の履歴を保持 | Smart QA、1席あたり$20のアドオン、またはEnterpriseに含まれる |
Zendeskでは、あらかじめ用意されたAssignee activityタブで、担当者ごとの速度と品質の列のほとんどが得られます。新人1人と1週間に絞り込み、数字を記録し、繰り返します。複数の新人の1週目と4週目を1つの画面で比較するグラフが欲しい場合は、カスタムレポートが必要で、つまりExplore Professional以上になります。
QAの列については、Zendesk QAのReviewsダッシュボードが各被評価者の内部品質スコア（IQS）を傾向付きで一覧にし、時系列の品質カードは週単位で動きます。Zendesk自身のドキュメントは、「if any agents might require specific training」を示せると述べていますが、これは立ち上がり曲線を上品に言い換えたものです。これを支えるスコアカードの作り方は、私のZendesk QAスコアカードのガイドで扱っています。
Frontも同じ仕組みです。Team performanceテーブルにはチームメイトごとの送信メッセージ数、返信時間、対応時間が表示され、知っておくべき点として、Frontは返信した人に実績を計上します。担当者ではありません。新人のチケットに先輩が返信すると先輩の仕事として表示されるため、立ち上がりの追跡には好都合です。
新人ごとに1タブ、週ごとに1行のスプレッドシートで正直なところ十分です。ツールよりも、毎週金曜に記入する習慣のほうが重要です。指標の定義そのものは、私がまとめたZendesk Exploreの指標を見てください。再オープン数も詳しく見る価値があります。新人が意図せず数字を歪めやすいのがこの指標だからです。
立ち上がりの遅れは実際にいくらかかる？
立ち上がりには、請求書に現れない2つのコストがあります。1つ目は失われた生産量です。10週間、半分の速度の新人は、クローズしたチケットを生まなかった5週間分の給与に相当します。2つ目は先輩の時間、つまり最も優秀な担当者が自分のキューを処理する代わりに「これはどう対応する？」に答えて費やす時間です。
r/callcentresのスレッドのある返信が、その重みを一行で表しています。
"It costs a few thousand to onboard someone, giving them less than a month to get up to speed is crazy."
自分の数字を入れて、数週間の立ち上がりがチームにとっていくらの価値があるか確認してください。
デフォルトの数字（年6人採用、立ち上がり10週間、生産量は半分、先輩の時間は週5時間）では、立ち上がりのコストは新人1人あたり約$8,000、年間で$48,000です。3週間短縮すれば、年間でおよそ$14,400の節約になりますが、これは2週目の不安定な返信を受け取る顧客に起こることを数える前の数字です。急成長しているなら、立ち上がりは人員計画に入れるべきです。3月に入社した人は、6月まで一人前ではありません。サポートの人員配置計画のメモでその計画の立て方を示しており、カスタマーサービスチームの作り方のガイドでは採用面を扱っています。
立ち上がりの週は実際どこに消えている？
ここは、最初の週の前に誰かに教えてほしかった部分です。立ち上がりは「学習」という1つの大きな塊ではありません。異なる対処が必要な、まったく別の2種類の作業です。
調べる時間とは、答えを探すのに費やすすべての時間です。どのマクロが当てはまるか、返金ポリシーはどこにあるか、先月チームがまさにこの質問にどう答えたか。r/mspのティア1の技術者は、これが自分にとって最も時間がかかった部分だと述べています。
"If they're a T1, I believe what took most time for me was to learn/remember where everything was located rather than the specifics."
判断力はそれ以外のすべてです。怒った顧客を読み取る、返金の例外が妥当なときを知る、手遅れになる前にエスカレーションが必要なチケットを見抜く。これを教えるドキュメントはありません。実際のやり取りをこなし、それにフィードバックをもらうことで身につきます。
私が最もよく見る間違いは、調べる時間の問題に判断力向けの対策を当てることです。見学を増やす、座学の週を延ばす、ロールプレイを追加するなどですが、新人に本当に必要なのは答えをより早く見つける手段です。逆の間違いは、優れた社内ナレッジベースがトーンを教えてくれると思い込むことです。教えてくれません。
チーム向けにサポート用wikiを作ったHacker Newsのコメント投稿者は、両方の効果を同時に報告していました。
"I was able to reduce training times by 75% because I created a curriculum that worked way better. I created a wiki for the support team and they were able to reduce call times by 40% because they had a place with the answers to the questions they were tired of answering."
1人による自己申告の数字ですが、私が見ているものと一致します。調べる時間は安く削れる部分であり、最初の1か月で最大の割合を占めることが多いのです。
サポート担当者の立ち上がり期間を短縮する方法：効果のある6つのこと
どれも特別なものではありません。コツは、正しい順番で行い、それぞれが解決する山に対応させることです。
1. 最も多いチケットから教える
ほとんどのキューは、少数の質問タイプに占められています。r/callcentresのある電話担当者は「80% of calls are about the same thing」と述べています。前四半期のチケットタグ上位10個を洗い出し、1週目はすべての機能を一巡するのではなく、それを軸に組み立てます。r/ITCareerQuestionsのヘルプデスク担当者はまさにそれを求めていました。
"Most common cases in a week: give me the rundown of the most common Dispatch and Tier 1 tickets you get in a typical week. I can figure out anything more specific from there as I go along."
上位10個が分からなければ、前四半期のチケットのナレッジギャップ分析で分かります。まだヘルプ記事がないものも見えてきます。
2. 一般的なロールプレイではなく、過去の実チケットで練習する
一般的なシナリオで学べるのは電話のマナーです。自社の解決済みチケットなら、自社のポリシーを学べます。r/CustomerServiceの返信は、一般的な研修だと現場に出てから「it will take them forever to figure out how your company wants something done」と警告しています。
簡単な方法はこうです。上位タグから解決済みチケットを30件選び、担当者の返信を隠して、新人に自分の回答を書かせ、チームが実際に送った内容と比較します。Zendeskサンドボックスは、顧客に影響を与えずにマクロやフィールドを練習するのに役立ちますが、含まれるのはEnterpriseプランのみ（Support Enterpriseで1つ、Suite Enterpriseで2つ）で、Support ProfessionalとSuite Growth以上ではアドオンとして販売されています。Freshdeskはサンドボックスを Enterpriseプランに掲載し、設定をテストするツールと位置づけています。これはFreshdeskサンドボックスのガイドで扱っています。
3. キューを段階的に開放する
新人を1日で見学から全キューへ切り替えてはいけません。先ほど引用したMSPの計画が良いモデルです。1週間の導入研修、1週間の見学、2週間の低優先度チケット、1か月の標準インシデント、そして「at the 3 month mark. If the staff member feels they are ready.」にオンコール。（出典）
ヘルプデスクでは、段階化はほぼルーティングです。新人を、最も簡単なタグだけが届くグループに入れ、数字が出てきたら広げます。共有キュー管理のガイドで、各ヘルプデスクの設定を扱っています。Zendeskではグループとトリガーの組み合わせで、Zendeskのルーティングで解説しています。Freshdeskでは、新人に限定的なスキルを割り当てるスキルベースルーティングで実現できます。
4. 先輩が見守る中で、自分で操作させる
先輩の作業を見学するのは生産的に感じますが、意外と学べません。MSPのチームリーダーは、2週間後にそれを逆転させる方法を述べています。
"We start with screen share (trainer sharing to newbie) and after about 2 weeks we switch to newbie sharing with trainer, trainer comments/guides but forces newbie to "do" the things. Much higher knowledge retention when they do it with guidance over just having them watch one of us do things."
チケット版は「下書きして、承認する」です。新人がすべての返信を社内メモとして書き、先輩が承認または編集し、その修正が学びになります。最初は先輩にとって遅くなりますが、だからこそステップ5があります。
5. すべてのチケットで最初の下書きを渡す
ここで、AIは調べる時間の面で真価を発揮します。エージェントアシストツールはチケットを読み、該当するヘルプ記事、マクロ、過去の返信を見つけ、新人が確認、編集、送信する回答を作成します。何を送るかは新人が決めます。白紙の入力欄から始めることも、返金ポリシーの場所を先輩に聞くために待つこともなくなるだけです。
担当者がAIの下書きを実際にどう使うかを長く観察してきましたが、私が見たあるトライアルでは、担当者が下書きをそのまま送ったのは12%だけでした。書き直しの大半は長さとトーンに関するもので、下書きは長く、チームのスタイルは短いのです。新人にとってはそれが有用です。下書きが正しい事実を与え、自分で行う修正がチームのスタイルを教えてくれます。AIがチーム自身の送信済み返信で学習していれば、そうした書き直しは減ります。
私が頼りにしている証拠は、私ではなく顧客から来ています。YellowdigのDirector of Support & Operationsは、eeselを導入した後にこう共有してくれました。
"Recently, a new customer success hire joked that our eesel AI bot was their best friend during onboarding and interviewing."
また、vfm Groupは先輩の時間の面について、新人がコパイロットを使って情報源から答えを見つけるようになった後、「Managers are now asked the important questions」と述べています。これが、調べる山が縮むということです。このカテゴリ全体については、AIエージェントアシストツールのまとめをご覧ください。初めての方は、AIコパイロットがサポートチームに何をもたらすかから始めてください。
6. 実際のやり取りで週次コーチングを行う
判断力はフィードバックで縮まりますが、そのフィードバックは本人の実際のチケットに対するものでなければなりません。ClassPassは、MaestroQAの記事によると、最初の60日間、新人のチケットのより多くの割合を毎週評価者に回していました。これは正しい発想です。最初は新人に手厚くQAを行い、その後減らしていきます。
本人のチケット5件を扱う30分の週次セッションは、50件を見る月次レビューに勝ります。Zendesk QAのコーチングダッシュボードは、コーチングセッションがIQSにどう影響するかを示し、先ほどのスコアカードと循環をつなぎます。
コーチング自体については、サポート向けAIエージェントコーチングが週次のリズムを解説しています。スコアカードツールを選ぶなら、サポートQAツールのまとめで選択肢を比較しています。
立ち上がりを長引かせる間違い
私が読んだほぼすべてのスレッドに、同じいくつかの間違いが出てきます。
| 間違い | 立ち上がりへの影響 | 対策 |
|---|---|---|
| キューを埋めるために研修を削る | 1か月目にミスが積み重なり、先輩は節約した時間を後始末に使う | 最初の2週間は守り、代わりにキューを段階化する |
| 毎日違う人の見学につく | 新人は同じチケットへの5通りのわずかに異なる答え方を学ぶ | 最初の1か月は担当のバディを1人決める |
| 最初の単独チケットだけを測る | 2週目に立ち上がったように見えるが、実際は3か月目 | 3つ目の旗まで4つの数字を追跡する |
| 誰も見つけられないドキュメント | ポリシーを覚えた後も、調べる時間が長く残る | Slackナレッジボットやヘルプデスク内の下書きなど、担当者が働く場所に答えを置く |
| 一般的なロールプレイ | 担当者はマナーを学ぶが、自社のポリシーは学ばない | 自社の解決済みチケット30件で練習する |
最初のものが最も多く、最も高くつきます。r/callcentresのある担当者はその結果を述べています。
"My job is similar understaffed and threw us on the phones after 1 week of training. My 1st month on the phones I had 25 errors and I literally learned trial and error."
この人は3か月目にミスゼロに到達したので、立ち上がりは確かに起きました。ただ、研修の中ではなく、顧客相手に起きたのです。もう1つの静かな問題は、先輩の頭の中にしかない知識です。そうした人が辞めると、今後のすべての新人の立ち上がりが遅くなります。だから、小さなチームでもナレッジ移転の習慣が重要です。シフトの引き継ぎと同じように、難しいチケットをチームがどう処理したかを書き留めることは、最も安上がりな立ち上がりへの投資です。
立ち上がり期間のためのeesel
eeselは、仕事のために雇うAIチームメイトで、そのヘルプデスクチームメイトは立ち上がりの「調べる」半分を担います。ヘルプデスクに接続すると（最も一般的なのはZendeskで、Freshdesk、Gorgias、Help Scout、Frontでも動作します）、ヘルプセンター、マクロ、過去のチケットから学び、新人が確認、編集、送信する社内メモとして返信を下書きします。先輩が修正すると、その修正は指示に反映されるため、次の新人は初日からより良い回答を得られます。
自分で何かに回答させる前に、実際の過去のチケットでシミュレーションを実行し、その返信がチームの送信内容とどう比較されるかを確認できます。eesel自身のドキュメントの例では、過去20件のチケットのうち17件がチームの返信品質と一致し、残りには優先順位付きの修正案が示されました。
どのプランでもシート数は無制限なので、研修中の全員が料金を増やさずに使えます。100クレジット付きの無料プランがあり、有料プランは月$299からです。次の新人が数週間後に入社するなら、初日から下書きを作らせておく価値があります。eeselを試す。