採用に頼らずカスタマーサポートを拡大する方法

なぜ「とにかくエージェントを増やす」が通用しなくなるのか

すべてのサポートリーダーがこれを経験している。チケットは顧客基盤とともに増え、だからチームもほぼ同じペースで増やす計画を立てる。それはしばらくの間はうまくいく。しかしいずれ機能しなくなる。なぜならチケット量と収益は実際には連動して動くわけではなく、そのギャップはスプレッドシートに現れるよりずっと前に燃え尽き症候群として現れるからだ。

Rampの共同創業者Eric Glymanは、以前のスタートアップParibusについてこんな話をしている。2015年のYCオフィスアワーのセッションで、彼の2人だけのチームは週次20%成長を報告し、彼らの「最大の問題」はサポートチケットが多すぎることだった。彼らが提案した解決策は、それだけのために3人目を採用することだった。Jessica Livingstonはこう反論した。

"If our solution was to hire someone to deal with customer issues, then next week when we grew more we'd have to hire another person, then another, and so on... You can't out-hire a bad product, or compensate for poor taste with a big support team."

Eric Glyman (@eglyman), co-founder of Ramp, X

それが罠だ。2万以上のヘルプデスクと8,000万件のチケットを対象にしたZendesk自身のベンチマークによると、平均的なサポートチームは月777件のチケットを処理し、稼働エージェント1人あたり294件、平均初回応答時間は24.2時間だった。しかし本当の物語は企業規模別の内訳にあった。従業員1099人と100499人の企業、つまりまさに拡大中のスタートアップの多くが置かれている成長段階の企業が、どの規模帯よりも群を抜いて重いエージェント1人あたりのチケット負荷を抱え、極小規模のチーム(91%)や従業員5,000人以上の大企業(82%、ただしエージェント1人あたりのチケット量ははるかに少ない)よりも低いCSAT(81~82%)を記録していた。Zendesk自身のアナリストははっきりとこう述べている。「As you grow, don't neglect your support team.」

これは古くからある企業だけの問題ではない。Yellowdigのサポート・オペレーション担当ディレクターはまさにこう表現している。「As a fast-growing startup with a small team, our customers far outnumber our employees. It's crucial that we have robust self-service solutions as well as tools to supercharge the efficiency of our client-facing teams.」私はこの手の話を絶えず耳にする。月に約7,000件のGorgiasチケットを抱えるDTCサプリメントブランドの運用リーダーは、チームが追いつけなくなり、生き残るためだけにメール量の少なくとも半分を自動解決する必要があると話してくれた。

上のチャートは問題全体を一つの形で示している。採用は量に対してほぼ線形にしかスケールしない(しかも量よりも遅い。新しいエージェントの採用と立ち上げには数か月かかるからだ)一方で、自動化はスパイクが起きたその週のうちに吸収できる。

人員でスケールすることが実際にいくらかかるのか

何かを自動化する前に、「とにかくエージェントを増やす」ことの本当のコストを試算しておく価値がある。なぜなら表示価格は決して給与だけではないからだ。

HDIのためのMetricNetのチケット単価調査では、北米で1人のサービスエージェントを補充するコストは、採用活動、経歴確認、研修、そしてフル生産性に達するまでの立ち上げ期間を含めると約12,000ドルにのぼるとしている。そして人員のオーバーヘッドはエージェント自身だけでは終わらない。典型的なサービスデスクの総人員のうち、顧客対応の直接エージェントはわずか約78%で、残り22%はチームリーダー、QA、スケジューラー、マネジメントであり、これらもチケット量に合わせてスケールする必要がある。チケットに答えるエージェントだけではない。

離職はまさに余裕がない瞬間にこれをさらに悪化させる。Salesforceのステート・オブ・サービス調査によると、サービス担当者の12%が過去1年で退職しており、Salesforce自身の言葉を借りれば、彼らは「often hard to replace」だ。退職するエージェントは暗黙の製品知識を一緒に持ち去ってしまうからだ。私はこれを直接目にしたことがある。Freshdeskを使うフランスの公共セクター向けITサービス企業の営業担当者は、その年に深い製品知識を持つ2人のシニアエージェントが退職したと話し、その知識が失われる前にAIのナレッジベースに取り込みたいと語っていた。

一方で、担当者が実際に顧客対応に費やす時間は減っているにもかかわらず、顧客の期待は上がり続けている。Salesforceの調査では、サービス担当者の82%が顧客の期待は以前より高くなったと答えているが、担当者が顧客と直接向き合う時間は半分未満の46%にとどまり、残りは社内の事務作業に費やされている。そして失敗への許容度は薄い。ZendeskのCX Trends 2026レポートによると、CXリーダーの85%が、たとえSLA上は問題なかったとしても、顧客はたった一つの未解決問題でブランドを離れると答えており、スタートアップのリーダーに限るとこの数字は90%に上る。

もう一つのレバー: セルフサービスとディフレクション

AIエージェントがチケットに触れる前に、最も安価なスケーリングのレバーは、そもそも顧客がチケットを開く必要がないようにすることだ。Salesforceの調査によると、単純な問題については顧客の61%がセルフサービスを好むと答えており、セルフサービスの導入度は優れたサポート組織と劣ったサポート組織を分ける最も明確な違いの一つだ。高パフォーマンスのサービス組織の80%がセルフサービスオプションを提供しているのに対し、低パフォーマンスの組織はわずか56%だ。HubSpot自身の調査もこれを裏付けており、CRMリーダーの78%が、顧客は実際には人間と話すより自分で問題を解決することを好むと答え、サービスリーダーの64%が2024年だけでセルフサービスへの投資を増やした。

実践的には、これは最新のナレッジベース、よくある返信のための一貫したマクロ、そして整理されたナレッジマネジメントを意味する。これにより、エージェント(およびその上に乗るAI)が同じ答えを5つのツールの中で探し回らずに済む。

私が話を聞いたフランスのPostmeの運営者は率直にこう言った。彼らのサポート問い合わせは、返金依頼、購読解除、注文追跡といった同じ一握りの繰り返しカテゴリーが大半を占め、1日500件以上に上る。これはまさに、人間が目にする前にセルフサービスとチケットディフレクションが吸収するために作られた種類の量だ。

社内ITヘルプデスク自動化ツールに関するG2のレビュアーは、その効果をカスタマーサポートにそのまま当てはまる具体的な数字で説明している。

"[The tool] is taking 100 tickets in a day and solving for over 80% of the actual request which in turn means my ticket volume that my team and I have to work on has decreased by 80% which leaves us time to focus on bigger projects."

Verified user review, G2

そしてRedditでも、チケットの急増に溺れかけている成長中のMSPについてのスレッドでのアドバイスは同じくらい率直だった。

"If your problem is low level tickets, you need to either hire more level 1 staff, hire higher quality staff, or automate the common issues away."

Top comment, r/msp, Reddit

これが決定木のすべてを一文にまとめたものだ。より多く、あるいはより質の高い人材を採用することはどちらもコストと線形にスケールする。よくある問題を自動化して取り除くことだけが、3つの選択肢のうち唯一そうならないものだ。

AIがチケットのライフサイクルで実際にどこに当てはまるか

ここで、硬直的なルールベースのチャットボットではなくAIエージェントがその場所を得る。チームの代わりとしてではなく、繰り返し業務が人間に届く前にすべて捕まえる層としてだ。

このパターンは4つの段階に分かれる。

1. 自動でトリアージしタグ付けする。 チケットトリアージ用のAIは、届いた瞬間に受信チケットを読み取り分類する。人間がまだ何を扱っているかを把握する前に手作業で仕分けする必要はもうない。チケットタグ付けの自動化のガイドで設定方法を解説している。
2. 繰り返し発生する量については返信を下書きするか自動返信する。 よくドキュメント化されている高頻度の質問、返金状況、注文追跡、「パスワードのリセット方法」などについて、AIはレビュー用の返信を下書きするか、信頼できるようになれば自ら返信を送信する。ここがチケット自動化が最も早く成果を出す部分だ。なぜならこれはキューの中で最も量が多く、最も判断が不要な部分だからだ。
3. コイン投げではなく、確信度が低い場合にエスカレーションする。 これはチームが省略しがちなステップであり、最も重要なステップでもある。私が話を聞いたDTCサプリメントのCXリーダーは要件を率直にこう述べた。「The AI will never be able to answer 100% of the questions... 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の実際の確信度に基づくエスカレーションルールこそが、リスクを拡大せずに自動化を拡大できるようにする。通常どう設定するかはZendeskのAIエージェントエスカレーションとチャットボットのエスカレーションを参照してほしい。
4. 判断や関係構築のために人間の時間を確保する。 共感、交渉、あるいは本当の問題解決が必要なチケットは引き続き人に回されるが、その人はもう「注文はどこですか」というメッセージにも同時に溺れることはない。

このパターンを実際の規模で運用しているeeselの顧客には、月に10万件以上のドイツ語チケットを処理する完全自動化されたZendesk導入や、1,000件以上のヘルプ記事をナレッジベースに反映させたマルチエージェントのFreshdesk構成で月5万件以上のチケットを処理する別の顧客が含まれる。Gridwiseは、そのAIが導入初月にTier-1リクエストの73%を解決し、7日間のトライアルだけで結果が見え始めたことを確認している(詳細な内訳はヘルプデスクエージェントページを参照)。これらはどれも人員を増やして得られたものではない。

確信度に基づくエスカレーションが重要なのは、代わりの失敗モードが何もしないより悪いからだ。私は、ナレッジベースが「すべてのモデルに対応しています」と書いていたために、人間なら気づくニュアンスもなく、実際には会社のデータベースに存在しないブランドの車種について、ボットが顧客に自信満々に「はい、そのモデルに対応しています」と答えるのを見たことがある。自信満々に間違えるAIは、遅くても引き際を知っている人間よりも信頼を損なう。だからこそ解決率の追跡をCSATと合わせて行うこと、解決率単独ではないことが、規模を拡大する自動化を誠実に保つ鍵になる。

AIでサポートを拡大するのに実際いくらかかるか

この経済性が成り立つのは、料金モデルがチケット量と同じようにスケールする場合だけであり、ここで席数ベースの料金と従量課金が大きく分かれる。

席数ベースのソフトウェアは階段状に価格が上がる。しきい値を超えるまでは問題ないが、超えた瞬間、その席を100%使ったか10%しか使わなかったかにかかわらず、まるまる1席分の追加料金を払うことになる。eeselのような従量課金は、代わりに実際の量とともに動く。eeselは解決済みチケットまたはチャット1件あたり0.40ドルを請求し、プラットフォーム料金も席数料金も月間最低料金もない。そのため忙しい月は自動的に費用が増え、静かな月は自動的に費用が減る。

実際の量で計算するとシンプルだ。

私はGorgiasを使うEC事業者が週約700件のチケット(6週間で4,000タスク以上、単一週での最大は708件)を、諸経費込みで1件あたりほぼ1ドルで処理しているのを見てきた。これは、同じ量の急増をカバーするために追加採用していたら要しただろうコストのほんの一部であり、数週間に及ぶ採用と立ち上げの時間も不要だ。多くのツールが今も使う旧来の定額モデルでは、月額固定料金を払う低ボリュームアカウントの場合、AI生成返信1件あたり約20ドルという計算になるのを見たことがある。これに対して従量課金では1チケットあたり0.40ドルであり、その50倍の差は、料金モデルが低くて変動の大きい量をどう扱うかだけに起因している。

AIでサポートを拡大する際によくある間違い

うまく拡大できないアカウントでは、いくつかのパターンが繰り返し現れる。

• AIの確信度を二値的に扱う。 95%確信していようが30%しか確信していなかろうが、すべてに同じトーンで答えるAIは、いずれ顧客に自信満々の誤答を返してしまう。最初の悪い返信の後ではなく、初日から確信度に基づくエスカレーションを設定しておくこと。
• セルフサービスを整える前に自動化してしまう。 ナレッジベースが古かったり散らばっていたりすると、悪い回答の配信を速めているだけになる。まず元の資料を修正すること。その上に乗る自動化層よりも、ナレッジベースに対するトレーニングの方が重要だ。
• 非エージェントのオーバーヘッドを無視する。 最前線のエージェントではない22%の人員のことを忘れないこと。AIでチケット処理能力をスケールさせても、QA、スケジューリング、レポーティングがどうスケールするかを見直さなければ、ボトルネックを取り除いたのではなく単に移動させただけになる。成長にあわせてサポートチームがエージェントグループをどう構成するかを参照してほしい。
• 成長を罰する料金モデルを選ぶ。 現在の量では安く見える席数ベースや定額のツールも、量が3倍になった瞬間、スタックの中で最も高い項目になりうる。現在の量だけでなく、想定される将来の量でAIエージェントと人間のエージェントのコスト比較を計算してみること。

eeselを試す

私はサポートキューで十分な時間を過ごしてきたので、追いつくために採用し続けるサイクルを身をもって知っている。そしてそれこそがeeselがこのように作られている理由だ。eeselのAIヘルプデスクエージェントは、あなたがすでに使っているヘルプデスク、Zendesk、Freshdesk、Gorgias、あるいはその他半ダースほどのツールに接続し、初日から過去のチケットやヘルプドキュメントで学習する。つまり導入から何か月も経ってからではなく、次の量の急増が来る前から役立つ。料金が席数ではなく解決済みチケット単位であるため、月500件から2,500件へのスケールは採用の意思決定でも料金ティアの飛躍でもなく、単に予測可能な、より大きな月次の数字を意味するだけだ。

eeselを試すには、カードが必要になる前に50ドル分の利用クレジットで無料で始められる。既存のヘルプデスクに接続し、次の採用が本当にサポートエージェントであるべきか、それとも全く別の何かであるべきかを決める前に、それが何を解決してくれるかを確かめてほしい。