2026年に本当に重要なカスタマーサービスマネージャーの9つのスキル

スキルの一覧

その変化は、チームが気づいていようといまいと、すでに起きている

サポートキューにAIを導入するほぼすべての本気の会話で出てくる異議がある。実はそれはAIについてではなく、マネジメントについての話だ。

「AIは100%の質問に答えられるわけではない。しかしAIが答えようとして『すみません、これはわかりません』とだけ答えたとして、私は自分の7,000件のチケットすべてを見て回り、AIが本当に良い回答をしたかどうかを確認することはできない。それなら結局、意味が少し薄れてしまう。私が必要としているのは、自信を持って対応できるチケットだけを処理し、それ以外はすべて放っておいてくれるAIだ。」

Gorgiasで月に約7,000件のチケットを処理するDTC Eコマースブランドのカスタマーエクスペリエンス責任者

これは製品への不満ではない。この記事のテーマそのものであるスキル、つまり何を任せるべきかを知り、すべての判断を自分で再確認しなくて済むだけの可視性を作ることを、まさに説明しているマネージャーの言葉だ。それをうまくやれば、自動化はレバレッジになる。うまくやれなければ、最初の仕事を監査するだけの2つ目の仕事を新たに背負うことになる。

1. カテゴリではなく信頼度によるチケットトリアージ

トリアージの旧バージョンはルーティングルールだった。「請求関連の質問はPriyaへ、技術的な質問はティア2キューへ。」2026年版は、まったく新しい軸をもう一つ加える。システムがあなたなしで行動する前に、どれほど自信を持つべきか、だ。

失敗モードはAIが間違った答えを出すことではない。人間らしいトーンが必要なチケットに対して、AIが自信を持って間違った答えを出すことだ。あるバス追跡サービスのサポートマネージャーは、自社の導入計画を検討する際にはっきりとこう述べた。「Zendeskに届く問い合わせの60%を処理し、より良い分析と解決のために本物の人間を呼ぶべきタイミングを分かっているシステムが欲しい。」この「タイミングを分かっている」という部分こそが本当のスキルだ。これは一度設定すれば終わりの設定項目ではない。どのチケットタイプなら完全自動化しても安全か、どれが人間によるレビュー付き下書きを必要とするか、どれがAIに一切触れさせるべきでないかを、継続的に判断し続けることなのだ。

固定的なカテゴリリストではなく信頼度ベースのルーティングこそが、多くのマネージャーがAIを「慎重に扱ってほしい」と言うときに実際に意味していることだ。

実際には、これは新入社員の最初の1週間をレビューするのと同じように活動ログを確認することを意味する。すべてのミスを捕まえるためではなく、それが10回の同じミスになる前にパターンを見つけるためだ。

このスキルを自分自身で構築しようとしているなら、まさにここでeeselのヘルプデスクエージェントが役に立つように設計されている。得意なチケットには全幅の信頼を持って回答し、それ以外は静かにチームのキューへ引き渡すよう調整できるため、キャリブレーションの判断はオール・オア・ナッシングではなく、あなたの手元に残る。それはチームの代わりではなく、トリアージというスキルを頭の中だけでなく実際の規模で実践可能にするものだ。

2. スポットチェックではなく、AIが採点したQAからのコーチング

多くのサポートチームは、いまだに昔ながらのやり方で品質保証を行っている。マネージャー(あるいはQA担当者)が月に数件のチケットをエージェントごとにランダムに抽出し、ルーブリックに沿って採点し、何かがおかしければコーチングの会話を予定する。この計算は実際には成り立ったことがない。エージェント1人あたり月に5〜10件の会話をレビューするというのは、多くのチームが実際に管理できている量とほぼ同じだが、それはつまり、誰かの本当のパフォーマンスのごく小さく、しかも代表性があるとは限らない断片からコーチングをしているということだ。

Bufferの25人からなるカスタマーアドボカシーチームは、レビュープロセスを切り替える前にまさにこの問題に直面していた。チームを率いるRoss Parmly氏は、そのサンプリング方法を率直にこう説明している。

「私たちはアドボケイト1人あたり月に5〜10件の会話をレビューしており、在籍期間、現在のパフォーマンス上の懸念、高評価の実績に応じて数を増減させています。」

Ross Parmly氏、Zendeskカスタマーストーリー

Bufferは自動採点への切り替え後、手動レビューにかかる時間を半分に削減した。これによって空いた時間は、トランスクリプトを眺めることではなく、実際のコーチングの会話にそのまま充てられた。それこそがスキルだ。自分でもっと多くのチケットをレビューすることではなく、すべてのチケットを採点する仕組みを構築し、1対1の時間を本当に会話する価値のある外れ値に振り向けることだ。

3. チームが実際に達成できるSLAの管理

初回応答SLAを設定するのは簡単だ。チームを疲弊させることなく、月ごとに95%の確率で達成できるSLAを設定することこそが本当のスキルであり、以前より難しくなっている。応答量の一部は今やAIによって解決され、一部は依然として人間の対応が必要なため、従来の一律のSLA計算がきれいには当てはまらなくなったからだ。

ここでのマネージャーレベルの一手は階層化だ。優先度レベルごとに異なる目標を設定し、初回応答と完全解決に別々の時計を持たせることで、緊急のチケットがルーティンなチケットと同じバケツに入らないようにする。当社のSLAベストプラクティスガイドではこうした階層の設定方法を、こちらのAI SLAガイドでは新しく生じた部分、つまり自動化された解決が「時間通り」という言葉の意味そのものをどう変えるかを扱っている。特にZendeskを使っているなら、目標そのものに手を付ける前にSLAトラッキングとマネージャー向けチケットビューを整備しておく価値がある。見えないものは階層化できない。

4. 管理者ではなく顧客のためのナレッジベース作成

これは頻繁に見られる問題であり、マネジメントのスキルとして語られることはほとんどないが、実際にはそうなのだ。あるサポートマネージャーのナレッジベース全体は、実際にヘルプセンターにたどり着く一般顧客ではなく、社内の管理者向けに書かれていた。すべての記事が実際の顧客には持ち得ない前提知識を仮定しており、それを参照するすべてのエージェント(人間もAIも)が同じギャップを引き継いでいた。

これは他人に任せられるドキュメント作成の問題ではない。ヘルプ記事における「完成」とは何を意味するかという、マネジメントの判断そのものであり、それは積み重なっていく。分かりにくい記事は一人の顧客を混乱させるだけでなく、エージェント(あるいはAI)がそれを参照するたびに間違った答えになる。ナレッジベースを能動的なインフラとして扱い、管理者の視点ではなく顧客の視点でレビューし書き直すことは、マネージャーが他人に任せるのではなく直接自分で担うべき、最もレバレッジの高い仕事の一つだ。

5. モラール向けの特典ではなく業務量を減らすことでチームをバーンアウトから守る

サポートにおけるバーンアウトは、ウェルビーイングの問題という衣をまとった、主に業務量と反復の問題だ。HubSpot自身のサポートブログは、Toister Solutionsの調査を引用して、コールセンターエージェントの74%がバーンアウトのリスクにさらされているとしている。ピーク時のキューを管理した経験があれば、この数字が誇張だとは感じないはずだ。(HubSpotのサポートブログ)

この痛みについての実際の会話に登場するチームは、ウェルネス手当を求めているわけではない。ある小規模なEdTechサポートチームを率いるディレクターは、「顧客対応チームの効率を大幅に高めるツールに加えて、堅牢なセルフサービスソリューション」が必要だと表現した。というのも、顧客の数がすでにスタッフの数を上回っており、どれだけ励ましても構造的な業務量のミスマッチは解決しないからだ。Zendeskを使う別の小規模なEコマースチームは、もっと率直にこう述べている。AIは「もっと簡単なもので容易に答えられる質問に、小さなサポートチームが押し流されることから救ってくれる。」マネジメントスキルとは、どの痛みが構造的なもの(反復的なチケットが多すぎて人手が足りない)で、どれが実はコーチングや人員配置の問題なのかを見極め、正しい方を修正することだ。サポートのスケーリングは、あらゆる急増を先回りして採用するだけでなく、この考え方の実践版と言える。

6. 優秀なエージェントが去る前に暗黙知を捉える

自治体の公共部門顧客を支援するフランスのIT サービス企業は、ERPトラブルシューティングに関する深い知識を持つ2人のシニアエージェントを同じ年に失おうとしていた。計画は送別カードではなく、彼らが去る前にその知識を「AIに取り込む」ことだった。この直感こそがスキルだ。去りゆく専門家のチケット履歴を、単に管理すべき退職案件としてではなく、知識を捉える窓として扱うことだ。

具体的には、誰かが一度書いてそのまま忘れられた汎用のFAQドキュメントではなく、優秀な人材が実際に解決してきた過去のチケットで、使用しているシステムをトレーニングすることを意味する。それは製品を説明するナレッジベースと、優秀なエージェントが難しいケースを実際にどう考え抜くかを反映したナレッジベースとの違いだ。

7. 実際に行動を変えるキャリブレーションセッションの実施

複数のレビュアーが同じチケットを採点し、意見をすり合わせるグループQAキャリブレーションは、チーム全体で採点の一貫性を保つために昔から存在してきた。2026年には、それに二つ目の役割が加わる。レビュアーの判断をモデルの判断と照らし合わせ、両者がどこでどう食い違うのかを突き止めることだ。既存のQAツール内でAIエージェントのパフォーマンスを評価することと、本物のエージェントQAフィードバックループを構築することは、今やどちらもより重要になっている。人間同士だけを比較するキャリブレーションセッションは、AIの信頼度とレビュアーの判断が静かにずれていく部分という、全体像の半分を見逃してしまうからだ。

8. サポートデータを経営陣が実際に行動する物語に変える

月次サポートレポートには構造的な問題がある。それが届くころには、そこに描かれている急増はすでに終わっている。「顧客は私が月次レポートを作るのを待ちたがらない」とは、あるカスタマーエクスペリエンス責任者が、キューで実際に何が起きているかへのリアルタイムの可視性の代わりとして振り返り型の分析を受け入れるよう求められたときに、それをきっぱりと拒否した言葉だ。

マネージャーレベルのスキルは、問題を実際に予測する一握りの数値、つまりスプレッドシートに埋もれさせるのではなくほぼリアルタイムで追跡する正しいカスタマーサービスKPIを選び出し、それを人員追加、SLA階層の調整、さらなる自動化への承認といった、経営陣が実際に下せる判断へと翻訳することだ。現在のダッシュボードがクローズしたチケット数しか追跡していないなら、AIサポート指標のこの解説が良い出発点のリストになる。

9. チームの信頼を失わずに新しいツールを導入する

これは、このリストの他のすべての項目がそもそも実現可能かどうかを左右するスキルだ。うまくいかない導入、つまり顧客の目の前で、予告なく、AIが一度でも自信満々に間違った答えを出すことは、たった一度の午後でチームと顧客の信頼を焼き尽くし、その後6か月かけて再構築する羽目になる。

私たち自身、これが起きるのを何度も見てきたため、今では何かが本番稼働する前に、必ず顧客の実際の過去のチケット履歴に対してすべての導入をシミュレーションしている。自信満々に聞こえるボットが誤った回答をすることこそ、チームの自動化への支持を永久に失う最も手早い方法だからだ。ローンチ前にサポートAIをレッドチーミングすることは、同じ直感の技術的なバージョンと言える。失敗モードを実際の顧客の前ではなく、テスト環境の中で見つけ出すことだ。

eeselを試してみる

サポートチームを管理しているなら、上記のスキルのほとんどにおける実際のレバレッジは、突き詰めると一つのことに集約される。反復的でリスクの低いチケットをチームの担当から取り除き、マネージャーにしかできないコーチング、SLAの調整、ナレッジベース作業のための時間を確保することだ。

eeselは、多くのチームがすでに使っているZendesk、Freshdesk、Gorgiasなどのヘルプデスクと連携し、初日から自社の過去のチケットとヘルプドキュメントから学習し、自信のあるチケットについては下書きの作成や自動解決を行い、それ以外はすべて直接人へルーティングする。これはまさにスキル1で扱った信頼度ベースの振り分けそのものだ。すべての自動化されたアクションは、実際にレビューできるアクティビティログに記録されるため、コーチングとレポーティング(スキル2と8)は月次の推測ではなく実データに基づくものになる。そして、あらゆる導入は事前に自社のチケット履歴に対してシミュレーションされるため、顧客対応の何かが本番稼働する前に、スキル9、つまりチームの信頼を勝ち取ることを実践できる。無料でお試しいただけ、クレジットカードは不要だ。